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Executive Summary 


In the process of implementing a Flight Deck-Based Interval Management Spacing (FIM- 
S) algorithm-based on the National Aeronautics and Space Administration (NASA) 
Airborne Spacing for Terminal Arrival Routes (ASTAR) trajectory based solution, this Air 
Traffic Management Technology Demonstration-1 (ATD-1) Avionics Phase 2 flight test 
team (Figure 1) learned how Interval Management (IM) operations can perform in the 
field. The prototype system was installed on the avionics of two commercial airplanes 
and tested during 19 flying days to assess ASTAR’s implementation and performance. 
The flight test program has very successfully demonstrated FIM operations on 56 
merging and in-trail spacing flights using a chain of three airplanes. The merging chain 
of airplanes tested a new set of air traffic control (ATC) voice clearances directing flight 
crews to achieve and maintain a given time-based or distance-based longitudinal 
spacing behind a target airplane. It enables new operations in either a voice or data link 
environment with new types of ATC advanced arrival procedures that reduce fuel burn 
and airport noise on arrival [1]. 


Figure 1. NASA ATD-1 Flight Test Team 


This NASA led effort involved collaboration between Boeing, the Federal Aviation 
Administration (FAA), Honeywell, and United Airlines. The FAA and NASA aim was to 
predictably achieve FIM-S inter-arrival precision of less than 10 seconds in-trail spacing 
error during the arrival phase of flight. Overall the FIM-S system and procedures show 
potential for consistent inter-arrival precision improvement across a wide range of 
operating environments and FIM-S clearance types. In practice controllers today achieve 
an average spacing error of 18 seconds in in-trail spacing without ATC ground tools. 
United is optimistic that NASA and FAA can further improve the spacing accuracies by 
combining FIM-S with new ATC ground tools [2] and provide a considerable boost for 
airport capacities. 
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The essence of these flight test statistics clearly show the power of the FIM-S system 
that takes large initial spacing errors at the FIM-S initiation point and delivers a much 
smaller spacing error at the Planned Termination Point (PTP). On 198 unique FIM-S 
operational runs, the NASA ASTAR algorithm implementation corrected airplane speed 
on average every couple of minutes with the pilot taking less than 10 seconds to execute 
the speed command. FIM-S was flown for both time-based and distance-based 
operations and the clearances tested included: 1) Achieve by then maintain (CROSS); 2) 
Capture then maintain (CAPTURE); 3) Maintain current spacing (MAINTAIN) and 4) 
Final approach spacing (SPACE) clearance types. 


UAL2197 N757HW N&889H / 


Figure 2. FIM-S Flight Test Procedures 


This avionics architecture implemented was one of the first Automatic Dependent 
Surveillance—Broadcast In (ADS-B In) spacing applications for arrival operations using a 
chain of three airplanes. It used the Electronic Flight Bag (EFB) to host NASA’s ASTAR 
algorithm, which could ultimately be available to retrofit airplanes favoring early fleet 
availability. By building prototype equipment without following all the processes of a fully 
certified development and test program, the Boeing, Honeywell, and United team was 
able to more quickly develop the FIM-S prototype to demonstrate a unique capability for 
in-trail spacing operations. The ADS-B In capability allows the pilot to execute the 
controller instructions in an effort to improve delivery accuracy while keeping the spacing 
appropriate for the particular phase of flight. This is not to say that the pilot assumes 
separation responsibility, but rather executes the controller spacing interval instructions, 
while flying the prescribed route, arrival, or departure procedure in the clearance. For 
this flight test program, ATC ground system personnel, assisted by the flight test 
director, were used to deliver airplanes to points on final cruise legs or on arrival 
procedures at spacing values that enabled high success rates for FIM-S operations to 
the runway. The arrival procedures were developed with the support of FAA Air Traffic 
and Flight Standards Organizations (see Figure 2). Transition into a Required Navigation 
Performance (RNP) Authorization Required (AR) approach procedure was utilized with 
the intent of allowing efficient decent profiles (3 degrees) while providing appropriate 
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speed authority to participating flight crews. Procedures included speed and altitude 
constraints. The Flight Test Director communicated on a non ATC frequency directly with 
each of the participating flight crews as well as a designated flight test base station 
Telemetry Room at Boeing Field. This capability allowed the flight test director to assist 
in the setup of the scenarios reviewed at the morning preflight briefing. Additionally the 
flight crews communicated with controllers at all five air traffic facilities on normal ATC 
frequencies, and current day pilot-controller roles, responsibilities, and phraseology were 
used. The Flight Test Director commanded the crew to enter Achieve-by and 
Termination Points. It should be noted minimum ATC separation was not stressed in 
favor of the accuracy of the Assigned Spacing Goal (ASG). Furthermore, it should be 
noted the efficiency of the overall flight operations could not have been accomplished 
without the daily support of the air traffic facilities involved. 


The NASA ATD-1 flight trial clearly demonstrated the feasibility of FIM as a means to 
maintain arrival capacity during low ceiling and visibilities or high winds by precisely 
controlling inter-arrival spacing. Although more development work is necessary for 
operational implementation, the FIM-S system tested during the ATD-1 flight trial met all 
but one of its design goals. It was remarkable to have the first prototype FIM-S system 
perform as well as it did. The one design goal not met was very close to being achieved, 
and is for one particular geometry and clearance type. The reason for not meeting this 
design goal is under study, and there is very high confidence that this clearance type 
and geometry will be corrected prior to any future FIM flight testing. 
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1 Introduction 


This report describes a prototype system built for experimental flight evaluations and 
research, and not intended for revenue flight. To understand how the team planned this 
Cost Plus Fixed Fee (CPFF) contract, it helps to know a little about the prior research 
and context for the contract. The Flight-deck Interval Management-Spacing (FIM-S) 
algorithm flown in Air Traffic Management Technology Demonstration-1 (ATD-1) Phase 
2 (P2) had been integrated into various simulators at National Aeronautics and Space 
Administration (NASA), Boeing and other simulation facilities prior to the initiation of this 
second phase of the ATD-1 program. The system was integrated into the Boeing 737 
Engineering Flight Simulator with hardware LRUs within the umbrella of ATD-1 Phase 1 
[1]. It demonstrated the use of ASTAR as a FIM-S merging and in-trail spacing 
application in a series of realistic FIM-S operational scenarios on a pair of arrivals to 
KPHX. The intent was to gain insight into real-world avionics implementations where 
ASTAR was hosted within the traffic processing functions. Honeywell has considerable 
experience with Airborne Basic Situation Awareness (AIRB) technology and the in-trail 
procedure (ITP) surveillance application hosted on an EFB architecture. The cockpit 
display of traffic information (CDTI) used in their ITP demonstration came from a system 
that had been certified for AIRB per DO-317A. ITP was developed for oceanic 
operations on 12 United 747 airplanes flying Pacific routes. 


These precursor activities provided much of the system requirements and served to 
mitigate risks of the flight test program. Under Phase 1, the following major tasks 
provided insight for IM applications: (1) FIM Feasibility Assessment during the NextGen 
midterm time frame (2016 to 2020) in forward-fit and retrofit options, (2) Trade Studies of 
28 architectures for both the 787-8 (i.e., an advanced avionics platform) and the 737NG 
(i.e., a significant US fleet for retrofit), (3) Concept Engineering Prototypes, and (4) 
Prototype Recommendations [3]. The final task resulted in Boeing’s recommendations of 
a prototype FIM-S system that led to the flight test program. In addition, a laptop running 
ASTAR was flown on the Boeing 787 2015 ecoDemonstrator as a proof of concept. The 
data from these flights helped to shape the P2 program and flight test. 


The airborne FIM architecture should fit into a broader air and ground (i.e., end-to-end) 
architecture. NASA already developed and turned over to the FAA the technology and 
elements of this integrated architecture during the past 20 years that help better manage 
portions of the nation’s air traffic control system (Figure 3). For example “Traffic 
Management Advisor” (TMA) was introduced in the NAS to assist with the flow of air 
traffic from the en-route to the terminal arrival airspace. Although TMA has been an 
effective tool to allow controllers to understand the traffic demand at selected airports on 
a quarter-hour basis it does not provide the desired level of accuracy to support 
significantly increased throughput. ATD-1 technology provides the future capabilities that 
will expand TMA to “Traffic Management Advisor with Terminal Metering” (TMA-TM). 
The new system will rely on enhancements to TMA by adding IM and Controller 
Managed Spacing (CMS). Collectively this technology is expected to provide controllers 
with the tools necessary to improve delivery accuracy to the destination runway. 


These ATD-1 FIM-S flight test demonstrate how more-frequent trajectory adjustments 
are made by the airborne system than is possible with TMA or other ground system tools 
alone so that increased levels of spacing precision on final approach can be achieved. 
The FAA continues to develop, test, and certify for operational use in the field these tools 
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Interval Controller Managed 
Management (IM) Spacing (CMS) 


Traffic Management Advisor with 
Terminal Metering (TMA-TM) 


Figure 3. ATD-1 Goals and Technologies for Integrated (End-to-End) Arrival Operations 


before agency implementation and improve the level of spacing precision on final 
approach. While in practice controllers today achieve an average spacing error of 18 
seconds without metering tools (e.g., without TMA), Human-in-the-Loop experiments 
have shown average spacing errors of 12 seconds (e.g., TMA-TM, Ground-based 
Interval Management-Spacing). 


The FIM-S flight test results show that further improvements in spacing precision are still 
possible. For an on-time airline such as United Airlines, to whom arrival and departure 
rates are key to schedule reliability, such spacing improvements are directly translatable 
into economic benefits [1]. 


1.1 Scope, Schedule, Risk Mitigation Steps 


The Flight Test proposal included a FIM-S prototype development and flight test effort 
for up to three airplanes scheduled within 22 months from contract award (see the 
proposal Statement of Work [SOW)). This proposed schedule was driven by the 
availability of the United Airlines 737-900, which was not available during the holiday 
seasons (November — December and Spring Break) owing to the need for it to be 
returned to service to support United Airlines flight operations at these times. The 737 
was also not available during the busy summer season. The two airplane constraints 
compressed the flight test into a window between January and March. This compression 
imposed firm schedule constraints and program cost risk from the start. 
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Therefore, Boeing had to vigorously manage program scope and its team members 
rigorously abided by its contractual milestones to stay within the compressed schedule 
and CPFF cost constraints. Contract award determined the start of requirements 
allocation and design activities and therefore set one bound on the schedule, the other 
was set by the United Airlines 737-900 availability. Scope was set by the need to 
faithfully execute on the number of contractual flight test days (e.g., lost days for bad 
weather, poorly designed procedure, airspace availability) while managing risks of any 
impact on performance of bad or unusable data (e.g., system anomalies, hardware or 
instrumentation failures') Within these, the team was laser focused on eliminating flight 
test risks by leveraging previous work (e.g., ATD-1 Phase 1) and executing contracted 
tasks effectively, using a fixed software testing schedule with no margin for additional 
software build spirals and little margin for extra test cycles prior to flight test. As seen in 
Figure 4, the schedule did not allow for extended hardware-in-the-loop bench testing, 
ASTAR enhancements (e.g., those not defined in the allocated system requirements) or 
Human Machine Interface (HMI) evaluations. 


The resulting contract phases can broadly be divided into six areas as illustrated in the 
hashed gray bar at the bottom of the Figure 4 timeline. They were framed by contract 
deliverables and include requirements, design development, implementation, ground 
and flight testing, and data analysis phases. It was clear early on that only time was 
available for two software loads subjected to the system test plan formal testing prior to 
flight test. The effects of the compression did not leave margin for additional ground 
check out of the hardware to refine soeed commands and alert annunciations, to 
optimize data entry or to conduct pilot focus groups to review the usability of the 
software. 


United Full Motion 
B757 Airplane Flight Manual Simulators STARS validation 


Updated for RNP AR Approval NASA Risks Mitigations 


Joint NASA/ Boeing / Honeywell NASA Flight training —— Honeywell Risks Mitigations 
SW Load 1Testing Workshop workshop 11-28 & 12-5 == United Risks Mitigations 
9-28 & 2! =— FAA Collaboration 


=== Program Activities 


First flight Final flight 


Early Speed Ctrl Module Check-out test day test day 


Auburn ARTCC Workshops Against NASA ASTAR 


Airspace Coordination (multiple) 1-20 2-22 
2015 2016 2017 
System Requirements Detailed Design | Software Load 1 SW Load 2 Flight Test | Data Analysis 
A I I I IX I I I I I I Wy | A | 
Contract Award Preliminary Design Review Critical Design Review System ‘ontract End 
6-5 9-24 5-5 Acceptance 6-4 
Review ; AL Final Presentation 

12-15& 16 Final Original Outbrief 5-23 

Other NASA Milestones: a pen 

Briefing to RSD 13/01/2016 A ; 

‘i ; window window ____ Fixed Contract Constraints 
Flight Safety Review (FSR) 29/03/2016 1-6 > 2-9 — —Primary Contract Milestones 
Intro briefing to ASRB 14/04/2016 2-28 3-27 
LaRC and JSC IRB approval 22/08, 22/09/2016 
Operational Safety Review (OSR) to ASRB 08/12/2016 
Flight Safety Release (FSR) 12/2016 
Flight Readiness Review (FRR) 19/12/2016 


Figure 4. ATD-1 Avionics Development and Flight Test Contract Compressed Schedule 


1 The number of contractual flight test days was 18; there are 19 flying days in the data collection 
set attributed to the additional flying day terminated early due to a mechanical event. 
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Load 1 had to be completed to enable the start of system testing that ran in parallel to 
Load 2 development. The lack of spirals was mitigated by a joint NASA/Boeing/- 
Honeywell/United workshop to accelerate the discussions about hardware-in-the-Loop 
testing and the active NASA involvement in these tests as well as the software progress 
reviews. At the end of Load 2, a number of test issues, not critical for flight test, were left 
open for future work (Appendix A). Attributed. 


The success of the program is attributed to a very unique team, with all members very 
focused on the program testing needs, using additional in-house resources and investing 
considerable effort to ensure success within the above contract schedule constraints. 
ATD-1 Phase 1 precursor activities and related steps were vital risk reduction 
opportunities. They included the following steps: 


e Honeywell was selected for the Boeing ATD-1P2 avionics design tasks after an 
earlier ATD-1 phase 1 supplier was removed. 


e Flight test airplanes and test crews were competitively selected after ATD-1 phase 1. 
e Airline team members were competitively selected after ATD-1 phase 1. 


e The Boeing 787 eco-Demonstrator was flight tested with the ASTAR algorithm on 
board in March 2013, outside of the ATD-1 Phase 1 contractual deliverables. 


e Software development and testing was competitively bid. 


e Moses Lake was selected as test site over Denver International Airport. This allowed 
the team to decrease the proposed costs and assumed risks potentially ensuing from 
interrupted runs caused by ATC intervention. It allowed the team to minimized 
assumptions for time lost in transit, assumptions for airplane fixed-base operational 
costs and extended setup times, personnel travel costs, etc. 


e To emulate future navigation capabilities special Standard Terminal Arrival Routes 
(STAR) were developed connecting to Required Navigation Performance (RNP) 
Authorization Required (AR) Approaches. Although this created challenges in the 
development of the STARs and the certification of airplanes and flight crews, it did 
provide the desired navigational accuracy. 


e Simulator validation of the Jeppesen-developed navigation database and procedures 
were performed by United Airlines in a 737 full motion simulator at their Houston 
Training Facility. The simulator validation was attended by FAA AFS-460 specialists. 


Early in the project the risk of conducting three airplane experiments without conflicts 
with other traffic within the National Airspace System (NAS) was identified. To mitigate 
these risks, coordination with the air traffic facilities involved began one year prior to 
flight and included briefings on ADS-B IN, and FIM-S. The facilities participated in the 
procedure design and experiment execution. Daily “test cards” were developed for use 
at the operational positions with facility representatives attending pre- and post-flight 
briefings on a daily basis. 


ATD-1 program scope was always limited by the flight test performance objectives and 
the need for accelerated development. For all the risk mitigation and schedule constraint 
reasons cited previously, the program scope could not allow time for unplanned tasks. 
Risk and cost rational processes (e.g., those from the above schedule and funding 
perspective) had to be deployed at every gate to ensure ATD-1 success. 
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2 Summary of Design and Evaluation Activities 


The following sections summarize the sequence of ATD-1 P2 Avionics design, 
implementation and design evaluation activities (e.g., software testing, hardware in-the- 
loop bench testing) as actually executed. 


The Speed Control & Trajectory Generation (Spd Ctrl), Human Machine Interface (HMI) 
and System Engineering (SE) Working Group (WG) teams managed these tasks with 
everyone willing to participate in multiple WG meetings as necessary to achieve the 
essential milestones. The Spd Ctrl WG leaders were responsible for the ASTAR 
implementation, and the software development and unit testing. The SE WG leaders 
managed requirements and system level testing. The HMI and Hardware WG leaders 
insured that all the crew entry, display design features and hardware was ready for 
testing and installation. 


2.1 NASA ASTAR Algorithm Implementation 


NASA has developed an FIM-S algorithm, ASTAR, which constantly calculates the 
airspeed required to position the FIM aircraft at the Achieve by Point (ABP), at the 
assigned spacing goal (ASG) behind the target aircraft. ASTAR version 13 (revision 7) is 
the basis for the implementation of FIM-S in this program [4]. 


ASTAR contains both trajectory-based and state-based mechanisms for calculating the 
speeds required to achieve or maintain a precise spacing interval. The trajectory-based 
capability allows for spacing operations prior to the airplane being on a common path. 
ASTAR builds a 4-D trajectory flight path for both a target airplane and the FIM airplane 
based on the clearance assigned to each. It then employs ADS-B In messaging and 
onboard sensors to determine current position along the respective trajectories and 
calculates an estimated time of arrival (ETA) for each airplane to cross a common point 
(known as the Achieve-By Point — ABP). The difference between the ETAs (e.g., 97 
seconds) minus the desired time spacing goal (e.g., 90 seconds) is the spacing error 
(e.g., 7 seconds) the algorithm attempts to drive to zero with speed guidance displayed 
to the crew of the FIM airplane. The desired spacing goal is required to be met no later 
than when the trailing airplane crosses the ABP, which helps to keep speed guidance 
close to constraints found in published procedures. 


No NASA software was used under this program. The implementation process started 
with the System Requirements Definition Document (SRDD) [5] and ASTAR Description 
Document [4], to formalize FIM-S system and software requirements that were reviewed 
at the Critical Design Review (CDR — See section 2.4). The implementation of ASTAR 
in the prototype FIM-S system differs from the ASTAR version implemented in simulation 
at NASA in the following areas: 


e Final Approach Spacing control algorithm implementation: The ASTAR Description 
Document did not include treatment of this operation. 
e Distance-based operation adaptations: [4] includes time-based operations only. 


e Mach operations and Mach/CAS transition: [4] inhibited the generation of speed 
commands until both the Traffic to Follow (TTF) and ownship passed the first CAS 
constrained waypoint on their respective routes. 
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The Mach/CAS operational limitations, were considered a program flight test risk item 
early in the program. The following partial list of refinements or modifications in support 
of Mach operations where developed in the prototype to mitigate the flight test risks: 


e Refinements to the trajectory generation to handle implicit speed and altitude 
constraints. 


e Changes to the deceleration estimation process to account for differences in Mach 
and CAS regions. 


e Changes to the speed limit calculations. 
e Changes to the speed command quantization. 


e Development of a discovery algorithm for traffic cruise parameters. 


Figure 5 shows a functional block diagram of the FIM-S prototype implementation based 


on ASTAR. Honeywell implemented NASA’s ASTAR in the Speed Control software 
block in Figure 5. 
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Figure 5. EFB FIM-S Software Functional Block Diagram 


Figure 5 illustrates the Honeywell main FIM-S software application hosted on the UTC 
Aerospace EFB hardware platform, which comprises the main application, along with 
libraries that implement the Speed Control module implementing ASTAR, the Trajectory 
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Generator and Navigation Database functionality. It also contains the Input /Output (I/O), 
CDTI, data logging and thread management functions. The design and implementation 
of the software and CDTI are based on previous Honeywell ADS-B In / CDTI efforts, 
modified for the needs of ATD-1. The CDT] user interface appearance reflects both 
typical Honeywell human interfaces adapted to the guidance from NASA cockpit display 
and interfaces guidance documents [6] and Boeing’s design guidance. Further 
Honeywell software design details are found in ATD-1 Technical Reference manual [7]. 


2.2 Flight Test Airplanes and Equipment 


The flight trials demonstrated the FIM-S avionics system in an airspace environment that 
is characteristic of a commercial airport with a variety of instrument arrival and approach 
procedures. The team equipped two transport category airplanes (757, 737) anda 
business jet with compatible surveillance and flight deck capabilities. The Boeing team 
used the Honeywell 757 Flying Testbed airplane and its associated crew as one FIM 
airplane. It was modified to meet both the operational and data-gathering requirements 
for the program. United Airlines supplied the second FIM airplane and its crews, a 737- 
900 transport category airplane also modified with the FIM-S equipment. Honeywell also 
provided the designated traffic airplane, a Dassault Falcon 900 business jet; it served as 
the target airplane. It was equipped with ADS-B Out technology (DO-260B compliant) 
but did not have the FIM equipment installed and had limited data gathering capabilities. 
The three airplanes capabilities are summarized as follows: 


e Commercial transport category airplanes (757-200 and 737-900) and a regional 
business jet (Falcon 900 flown to follow a 737 flight profile). 


e 757-200 and 737-900 equipped with an ARINC 735B (DO-317A compliant) TPU 
that included the ADS-B In functionality. 


e 757-200 and 737-900 equipped with transponders providing ADS-B Out 
functionality (DO-260B compliant). Falcon 900 equipped with ADS-B Out only 
(DO-260B compliant). 


e All equipped with GNSS 


e 757-200 and 737-900 equipped with a Flight Management System (FMS) and 
other avionics capable of sourcing all required FIM data. 


e LNAV/VNAV and RNP AR capable or equivalent. 


e 757-200 and 737-900 capable of speed intervention through the Mode Control 
Panel (MCP). 


The FIM-S software is implemented in dual, UTC Aerospace Class 3 EFBs that are 
mounted as side displays on the flight decks of a 737-900 and a 757-200 airplane. In 
addition, two prototype configurable graphics displays (CGD) that provide speed 
advisories and other FIM situational awareness information to the pilots are installed in 
their primary fields of view. A Honeywell DO-317A-compliant Traffic Alert and Collision 
Avoidance System (TCAS) Traffic Processing Unit (TPU) provides the ADS-B In track 
processing capability, and this feeds the FIM-S application running in the EFBs. The 
EFBs provide the following capabilities: 


e FIM-S application 
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e Touchscreen data entry and application control functions 

e Display of FIM-S application entered and processed data 

e Traffic situational awareness through a Traffic Display 

e Output of speed guidance and situational information to the CGD. 


On FIM-S system initialization, one of the EFBs was designated as the Master, and used 
received and input data to perform the computations resulting in the provision of speed 
guidance and FIM situational awareness information. The Master EFB fed both CGDs. In 
case of EFB failure, the slave EFB must be restarted to allow it to be assigned the 
Master role and to provide information to the CGDs. Both Master and Slave EFBs can 
be used simultaneously for data entry and display selections are independent. Crew 
procedures were defined prior to flight test to ensure that a single data-entry field is not 
being addressed simultaneously by both pilots. 


Provision was made for the display, once sufficient data had been made available, of 
either current Measured Spacing Interval or Predicted Spacing Interval, depending on 
the type of operation planned, so that a suitable ASG could be entered for use in the test 
condition. This display was solely for engineering and flight test convenience and would 
not be part of a “production” system. 


Figure 6 shows the components of the FIM-S system (yellow) and the existing avionics 
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Figure 6 - FIM-S System Hardware/Software Configuration 
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that provide data to the FIM-S system (light blue). These data are partly FIM-S aircraft 
data and partly data from the target received via ADS-B. The DO-317A compliant TPU is 
largely production standard; most importantly, the TCAS function that resides in the TPU 
is fully production standard, and regression testing has been carried out to ensure that 
TCAS capabilities are unimpaired. 


Data identifying the designated airplane are fed back from the EFB’s Aircraft Interface 
Device (AID) to the TPU to ensure that the target airplane data are always available to 
the Traffic Display regardless of how many ADS-B equipped airplanes are providing data 
that are being processed by the TPU. 


The success of this flight test relied on extra communication capabilities including a 
Remote Communications Air Ground (RCAG) station at MWH, to enable 
communications from the airplane to the Boeing flight test operations center at Boeing 
Field. Satellite communications on the B757 allowed for the transmission of telemetry 
data, and airborne internet connectivity on all three airplanes for the reception of 
extensive telemetry data. An extra VHF communication radio was dedicated for flight 
test operations and was monitored in real time at the Boeing Field Telemetry Room. L- 
Band SATCOM was very useful as it is less susceptible to data loss during turns. GXa 
SATCOM was available to send and receive data that was not time critical. The 
Atmosphere Planet Software was critical in the surveillance of the flight test area, 
providing multiple airplanes progress and situational awareness off other test airplanes 
and traffic. Such communication capabilities should be available to all participating 
airplanes and monitoring rooms. Cell phones were utilized for the coordination of 
morning engine start, taxi and takeoff times. 


2.3 Prototype Hardware/Software Platform 


The cockpit hardware suite is composed of two side-mounted UTC Aerospace Systems 
EFBs linked to the avionics data buses through the UTC AID and loaded with the 
Honeywell-built FIM-S software. Two model SE iPhones are mounted in the forward field 
of view and serve as speed command indicators for each of the crew members. Figure 7 
illustrates the layout of both the EFB (left) and the iPhone (right). 


The primary job of the FIM-S system is to provide speed commands and status 
information to the crew when performing IM procedures under Instrument Flight Rules 
(IFR). Figure 7 shows a FIM-S CROSS clearance in paired mode; it illustrates the four 
FIM-S display items: An indication of whether the airplane is paired to the target airplane, 
the commanded speed (in knots or Mach) and two indicators. The first indicator shows 
whether the airplane is fast or slow relative to the target (FAST/SLOW Indicator — FSI) 
and the second shows whether the airplane will be early or late to a fix relative to the 
target ahead (Progress Indicator — Pl) which, in Figure 7, was 68 seconds early. The 
EFBs show route, nearby traffic, and other information to illustrate movement along the 
intended clearance within the IM arrival stream. Finally, Figure 7 illustrates a status 
message where IM SPEED LIMITED indicates that the commanded speeds exceed the 
profile performance bound (i.e., control authority) embodied in the design. Further details 
of the avionics interfaces used on the two FIM-S equipped airplanes is shown in Figure 6. 
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Figure 7. FIM-S Active Cross Clearance in Paired State 


Each of the crew members uses a side mounted EFB in landscape mode where the 
information entered by one crew member is cross-fed to the other display. This display 
device hosts the IM application, the IM data entry and display of traffic information. The 
EFB also computes the information displayed on the CGDs. Only a subset of the IM 
information needed information needed in the Primary Field of View (PFoV) is indicated 
on the CGD (speed, alert messages, etc.). Figure 8 illustrates the equipment location on 
the 757. 


Figure 8. IM System -- Equipment Location (757) 
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2.4 A Brief Overview of the Development and Test 
Process 


Despite the considerable ATD-1 Phase 1 precursor activities (see risk reduction 
activities and related events listed in section 1.1), significant systems engineering effort 
was required to review NASA’s proposed revisions to the FIMSRD [8] and ASTAR 
limitations at the start of the compressed contract schedule. It took several weeks to 
analyze and consolidate the FIMSRD in preparation for the Preliminary Design Review 
(PDR) meeting. Revisions to existing requirements were only made known after contract 
award and resulted in a month delay in the contract SOW’s scheduled PDR meeting. 


Once a complete system level requirements specification document was agreed on [5], 
the ATD-1 P2 program moved ahead to PDR and recorded an acceptable number of 
change board design items. The completed system requirements enabled quick 
allocation of flight test relevant requirements to the prototyped architecture, efficient 
development of software and hardware articles, and as much test verification as possible 
before the fixed start date for flight test. It was based on NASA’s prior ATD-1 work at 
various simulators facilities available to the government; industry work at RTCA, Inc. on 
the Minimum Operational Performance Standards (MOPS) developed in collaboration 
with the FAA, avionics suppliers and the airlines and Boeing’s Phase 1 and Honeywell 
prior work. The PDR focused on allocation of requirements to architectural design 
elements, review and recording of implementation notes for later detailed design 
consideration and the capture of implementation attributes (e.g., testing methodology 
assignment, testing notes). Strict management of the implementation steps flowed from 
these efficient processes consistent with a prototype development effort and insured the 
project’s ability to stay within cost and schedule constraints. Five working groups (WG) 
were assigned detailed design activities around the time for PDR. Their detailed design 
and implementation analysis activities each focused on the allocated requirements 
established by the early SE work. The weekly WGs meetings produced multiple design 
and test documents. The complete set of required documentation is loosely mapped 
against the five WGs’ activities as follows (only final document versions are listed in the 
references): 


e Speed Control WG [9] 

e Human Machine Interface WG [9] 

e System Engineering WG [5], [10] 

e Flight Test WG [11] 

e Data Collection and Analysis WG [11], [14] 


The primary testing objective was to assess the Honeywell software integrated with the 
installed avionics systems to ensure that the NASA ASTAR 13 algorithm was 
implemented correctly on the flight test hardware. The testing approach included a 
capability to execute a subset of the MOPS performance tests, those that were critical 
for flight test execution (see System Test Plan report approach and road map [10]). For 
example, to stay within time and cost constraints, system-level testing relied on the 
previous NASA testing to ensure that ASTAR 13 met the performance requirements of 
the MOPS. In areas were the ASTAR 13 algorithm did not meet the performance as 
defined in the MOPS or additional functionality was required, the team was not always in 
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a position to refine the algorithm or add functionality prior to flight test. Some changes to 
the ASTAR 13 algorithm were outside the scope of the testing scope and can only be 
referred to test recommendations and change impact assessments outside this program. 
The testing approach relied primarily on a subset of MOPS test vectors, procedures and 
the pass/fail system test criteria tailored to the program objectives and conditions 
expected to be encountered during flight test at Moses Lake. The performance 
requirements in the MOPS were not the primary testing objective for ATD-1 and there is 
no guarantee the flight procedures tested meet all the MOPS requirements. 


The primary means of testing was using software unit testing (i.e., preliminary software 
load) of integrated software items as defined by the joint WGs and performed by 
individuals or on actual hardware integrated with the Honeywell test environment. These 
tests were for items that required more explicit testing (i.e., software Load 1 and Load 2). 
Each development team performed these unit tests as part of the prototype development 
process; the detailed description of the overall process is provided in the System Test 
Plan (STP). The STP further describes our approach and overall test road map as 
follows: 


e Software Unit Testing Approach — high level description of how individual 
software modules were tested 


e Test Operations — high level description and description of the Honeywell 
simulated integrated software and actual hardware test environment 


e Integrated System Test — high level description and list of MOPS and other 
integrated system tests (e.g., CGD) 


e Other system tests including analysis/demonstrations/inspection, TPU testing, 
review of flight test procedures. 


The FIM-S development and testing phase was essentially concluded at System 
Acceptance Review (SAR), which was conducted over two sessions at Honeywell’s 
Redmond, WA, facility. Version 1.0 of the FIM-S software was reviewed three months 
earlier with attendance by NASA and other personnel to mark the start of integrated 
testing jointly with personnel from NASA/Boeing/Honeywell. This was focused 
collaborative integrated testing of the ASTAR algorithm implementation and refinement 
of MOPS and integrated testing scenarios. Existing Honeywell test equipment was used 
to generate traffic signals and ownship state data to fully exercise all aspects of the FIM- 
S system. The airplane model used for SAR and integrated testing was based on a 
version being developed for future MOPS testing. The complete system connected the 
FIM components (TPU, EFBs, CGDs, AID, Wireless Components and supporting 
equipment (e.g., engineering laptop used in flight)). Version 2.0.2 was reviewed in a 
second SAR session at the time when hardware installation test results on the airplanes 
became available and focused on successful completion of simulated flight test 
scenarios (e.g., setups and transitions between clearance types that would be used in 
the actual flight test rather than strictly following the MOPS test vectors. 


Throughout the program, the team maintained traceability between initial design 
requirements, mapped implementation verification definitions, and test artifacts at the 
system level using configuration controlled relational database tools (i.e., IBM Rational 
Dynamic Object Oriented Requirements System (DOORS) and other tools — see tables 
in Appendix A). System level traceability and documentation was maintained and 
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consistently updated throughout the review phases: PDR, CDR and SAR. The integrated 
software items (see the software unit testing approach in the STP for a detailed 
description) had been defined and allocated prior to PDR. 


2.5 FIM-S Software Description 


The FIM-S software was hosted across multiple physical devices following the allocation 
in the selected architecture by the SE WG. The selected architecture was initially 
proposed in the ATD-1 P2 proposal based on the ATD-1 Phase 1 architectural studies of 
feasible options that allowed the project to stay within the considerable cost and 
schedule constraints. 


The software functions, hosted on the avionics hardware, provide the following: 


e FIM-S Speed Control and Trajectory Generation functions hosted on the EFBs 
e HMI data entry and control functions hosted by the EFB 


e Speed guidance, speed/state changes, and crew alerts in the forward field of 
view displayed by the CGD 


e Traffic information from legacy hardware and traffic interface functionality 
computed on the DO-317A compliant TPU 


e Navigation database services and input/output control functions hosted by the 
EFB 


Figure 9 illustrates the software functional architecture with the two EFBs (captain and 
first officer) and two CGD displays (captain and first officer). Further, it depicts wireless, 
wired, Ethernet, and 429 connectivity between the various devices. The ASTAR 
algorithm is hosted on the EFBs by the speed control software function. The AID 
ensures that all aircraft bus data is transferred to the FIM-S application. 


The DO-317A-compliant TPU IO function has been modified to provide additional FIM- 
specific data but otherwise uses the existing Honeywell TPA-100B baseline software. 
Once the traffic to follow has been identified by the FIM-S application, the TPU ensures 
the target data is provided. Auxiliary functions such as data logging are further described 
in the reference documentation. 


The EFB-based FIM-S application was very complex and achieved excellent results 
soon after the start of the flight test program. Among the most challenging aspects of the 
software development were porting the speed control algorithm from a lab 
implementation to an avionics implementation, extending the algorithm to the clearance 
types not implemented in the current ASTAR release and developing an aircraft 
independent trajectory generator. 


The speed control development activity needed to address issues of real time 
performance of the EFB computers, master/slave operations for redundancy and 
synchronization of the HMI between the dual EFBs. There was also a significant amount 
of work involved in developing software requirements and designs to cover en-route 
operations and the final approach spacing clearance that had limited functionality in 
ASTAR 13. In particular, augmenting the algorithm for real time execution in the en-route 
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Figure 9. FIM-S Software Functions Allocation 


regime (Mach) was especially challenging and, as indicated in the open test issues listed 
in the appendix (see FIM open test issue #274), is still not completely satisfactory. 


Developing the trajectory generator (TG) was also somewhat challenging. Part of the 
challenge was to develop a completely aircraft independent TG. By definition, an aircraft 
independent TG does not use aircraft performance data but, in this case, this even 
includes such basic parameters as cruise speed and cruise altitude, so a special 
algorithm was developed to discover these parameters for the target aircraft. Another 
challenging aspect of TG development were all the ancillary functions assigned to this 
component. Although not strictly “trajectory generation” functions, to maintain functional 
coherence the design allocated the traffic history database and many of the 
time/distance calculations to the TG component. As a result, the actual TG component 
was a fairly complex piece of software. 


The accelerated pace of this project did not allow time for additional test cycles or added 
engineering flight tests before the scheduled FIM-S flight tests. A few aspects of the 
system did not work as well in flight as they had in lab testing as a result. Also, before 
the flight test began, and even early in the development phase, some issues were found 
in the lab testing that were deemed to not impact the performance of the system in flight 
and were recorded as deferred items to be fixed later in a future version of the system. 
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These items are listed in Table A-1 in Appendix A. Items noted at SAR and during the 
actual flight test are listed in Table A-2 and Table A-3, respectively. 


These issues required a few workarounds in the early days of the flight test. Over time, 
most of the issues requiring workarounds were corrected, resulting in the introduction of 
two operational software upgrades during the flight test. Each software change was 
analyzed to make sure that it would not invalidate previous quantitative results; runs that 
were affected by issues that were corrected in later software updates were excluded 
from the formal data analysis. 


In addition to the two software upgrades during the formal runs, a third software update 
was made that included an updated Nav DB with additional speed constraints on 
selected arrival procedures. This software version was used for qualitatively evaluating 
FIM-S performance on procedures with improved speed profiles better tailored to IM 
operations. 


The CGD design was kept very basic to minimize logic processing on the display device 
and to simplify the data flows with the EFB. All display information is provided through 
the EFB and no crew input is required during IM operations. The CGD leverages existing 
and emerging network and communication designs based on Ethernet, Internet Protocol 
(IP), and Wi-Fi capabilities built into the host device using standard software interfaces, 
protocols and device drivers. In fact, no resident software is hosted or executed on the 
CGD display hardware, only the commercial HTTP Browser is. This minimizes the 
latency, ensures same information is displayed on both the CGD display devices at the 
same time, and reduces display drawing complexity, latency, and jitter. This allows the 
flight test to focus on the display of airplane speed guidance and deviation indications in 
the flight crew’s PFoV with the necessary information to safely conduct airborne IM 
spacing. 


A timeline of the software versions and the flight test days they were used on is included 
in Appendix A The appendix also provides a complete list of the remaining open 
software issues. 


The chief CGD observation from 19 flying days is the CGD PFoV trend information (and 
identical EFB side display cues) provided throughout the merging and spacing 
maneuvers by the FSI and PI cues were not usable at all times. They did not provide 
accurate information regarding the airplane state following an assumed deceleration 
profile. Despite thorough testing during the implementation phase (no CGD jitter, 
latency, or drawing faults were reported during flight test or SAR) this usability 
performance aspect could not be further evaluated with available hardware in the loop 
ground tests and MOPS test vectors. MOPS guidance is silent on these design 
specification details for trend information; the HMI design was not finalized at the start of 
the program. The HMI WG lacked prior usability advice and could not finalize the 
implementation details (e.g., symbology, font sizes, scales) until shortly before integrated 
system testing (i.e., start of software Load 2 integrated testing). MOPS test vectors are 
not adequate on this issue. Placing the CGD in the PFoV was also challenging, 
particularly on the 737 owing to the small size of the flight deck. This required numerous 
discussions with Boeing SMEs and United crews to reach consensus on the best options 
for the flight test. Thanks to people’s skills and willingness to overcome testing 
challenges during an otherwise thorough implementation and testing phase, only valid 
CGD alert messages were observed during SAR and flight. All the off-route messages 
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that were observed during flight were correct. There were some IM speed-limited 
messages that were a little hard to understand but, after analysis, we determined they 
were calculated correctly. No additional issues were raised for misleading or hazardous 
CGD information. 


2.6 Design, Test, and Operations References 


NASA’s need to ensure technology transfer to the FAA can be assisted by the following 
design, test and operations descriptions of the primary aspects of the prototype. Details 
of FIM-S Avionics System’s design are split between the Boeing and Honeywell 
deliverables. Select documentation tasks where led by Boeing and resulted in Boeing 
documents (e.g., system requirements, CGD design, system tests, hardware 
documentation, data collection); others where led and documented by Honeywell (e.g., 
technical reference and operations/pilot manual, EFB design, HMI design, software unit 
tests) according to the team members work breakdown structure and their respective 
areas of design responsibility (i.e., Honeywell TPU, EFB, etc., and Boeing CGD and 737 
hardware). All documents were reviewed by the team members as part of the WG 
activities and the technical reviews; final document deliveries were done jointly. The 
highlight of primary documents further described is as follows: 


e Software Design Description [9] (Deliverable 4.4) 

e FIM-S Avionics Technical Reference Manual [7] (Deliverable 4.16) 
e FIM-S Flight Test Plan [11] (Deliverable 4.22) 

e FIM-S Avionics System Test Plan [10] (Deliverable 4.15) 

e FIM-S Avionics Operations Manual [13] (Deliverable 4.17) 

e Post-Flight IM Data Analysis report [14] (Deliverable 4.26) 

e System Requirements Definition Document [5] (Deliverable 4.8) 


This documents list, although extensive, was instrumental in maintaining documentation 
traceability as well as a disciplined and concise SE approach. The team strove to 
achieve the best fit for the various tasks through PDR, CDR, and SAR milestones with 
documentation updates as time and budget allowed. The disciplined approach paid 
dividends in the testing phases where it provided as much verification as possible within 
the constraints of the contract and minimized the risk of implementation errors or 
omissions that might have affected the flight test program. Consistent with a prototype 
development effort and to stay within cost constraints of the ATD-1 project, the testing 
and formal documentation traceability was limited to system requirements and focused 
on observations and recommendations relative to the MOPS (section 4.1.1). It did not 
provide the level of formal traceability or the depth as would be required for certified 
avionics but rather analyzed the System Requirements Definition Document (SRDD) to 
determine the best method to verify requirements. The verification methods, where 
defined in the SRDD and used in the System Test Plan (STP); further details are 
provided in the STP. A brief description of the key documents is provided in the following 
paragraphs. 


The Honeywell [9] and Boeing Software Design Documents (SDD) [12] capture the 
architecture of the EFB and CGD software system, subsystems and components 
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respectively. Specifically, the SDDs describe aspects of each software component and 
the surrounding context and interfaces. 


The FIM-S Avionics Technical Reference Manual [7] provides an overview of the 
technical design, operation, and performance of the FIM-S application and FIM-S 
avionics system. 


The Flight Test Plan [11] describes procedures for conducting FIM-S operations with the 
FIM-S Avionics Systems installed in two test airplanes. 


The STP [10] documents the procedures and the pass/fail system test criteria applied to 
the Honeywell and Boeing FIM-S software items in preparation for SAR. The test plan 
describes the testing approach and the expected test results at the system level for 
those Software Design Description (SDD) requirements that necessitate testing of 
integrated software items. The actual test results, exercised with hardware in the loop, 
where presented at SAR and documented in Table 2 of this report. 


The FIM-S Avionics Operational Manual [13] describes the operation and use of the 
FIM-S Application installed on an EFB. Specifically, this document includes (1) screen 
layouts for each page of the interface; (2) step-by step instructions for data entry, data 
verification, and input error correction; (3) algorithm state messages and error condition 
alerting messages; (4) airplane speed guidance and deviation indications; and (5) 
graphical display of the spatial relationships between the Ownship airplane and the 
Target airplane. 


The post-Flight Data Analysis Report (FDAR) [14] serves as the mechanism by which 
analysis of collected flight test data was delivered. It describes the data collected or 
derived as well as analysis methodology. Finally it includes associated results extracted 
from the data set collected during the ATD-1 P2 Flight Test and is summarized in section 
3 of this report. 


The SRDD [5] contains the actual allocation of requirements to architecture elements 
and associated implementation verification methods derived from the NASA system level 
requirement specifications [8]. The original document was based on the initial analysis 
products of the Boeing/Honeywell ATD-1 collaboration and was released to support PDR 
in September, 2015. The requirements were the basis for subsequent implementation 
efforts by the WGs. These requirements were accepted prior to FIM PDR and included 
associated attributes and supporting notes. Revision A was released after PDR and 
included changes identified during and shortly after the CDR. Revision B is the final 
version and includes findings from the pre-flight software implementation testing 
activities and the December, 2016, SAR. It supports the release of the companion ATD- 
1 Phase II STP document. 
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Figure 10. ATD-1 Project Documentation Tree 


The full design and flight test documentation was more extensive and was developed 
progressively throughout the program. A complete overview listing the requirements, 
design, test and operations documents for the program is provided in Figure 10. It 
provides a hierarchy tree centered on the Government Furnished Items (GF1) used to 
guide the implementation of ASTAR. The document tree, from the earliest contract 
deliverable (the Boeing SRDD and an initial Interfaces Control Document [ICD)]), is 
branched from left to right into requirements related documents, software and hardware 
design focused documents, and, finally, Test and Operations related documents (i.e., 
those following the program milestones time-line). The tree includes references to the 
GFI used to guide the FIM system implementation; it also lists the Contractual 
Deliverable Requirements List (CDRL) numbers under which the final document 
versions were delivered. Where proprietary information from the team members was 
used, documentation was provided in two versions: one limited version included 
proprietary materials (e.g., for internal use by government civil servants) and one 
unlimited to allow broader distribution with proprietary details simplified. 
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3 Summary of Flight Test and Data Analysis 
Activities 


The January 20 to Feb 22, 2017, ATD-1 flight test program was the result of 
considerable preparation activities designed to ensure success. The following sections 
summarize those accomplishments as well as describe the actual flight test results. The 
Flight Test and Data Collection WGs teams generated this material with everyone willing 
to participate with multiple WG meetings as necessary to achieve the essential 
milestones. The Flight Test WG leaders were responsible for the Design of Experiment 
materials and the Arrival and Approach procedures design described in the following 
paragraphs. The Data Collection WG leader assembled the data collection, and analysis 
results described in sections 3.3 and 3.4. 


3.1 Design of FIM-S Flight Test Experiment 


The experiment was set up for a merging chain of three airplanes — the Falcon first, 
followed by the 757 and the 737 in trail — executing high- and medium-altitude merges 
and in-trail trajectory-based operation, on RNAV routes coupled to precision RNP 
approaches to Runway 32R at the Grant County International Airport, near Moses Lake, 
WA. 


The flight test matrix is provided in Table 1 and describes the flight test conditions that 
were executed. The types of FIM-S clearances that were tested include the following: 


e Achieve by then maintain (CROSS) 

e Capture then maintain (CAPTURE) 

e Maintain current spacing (MAINTAIN) 
e Final approach spacing (SPACE) 


For the CROSS clearance type, the objective is to achieve a controller-ASG by the ABP, 
then maintain the spacing interval until the PTP. This clearance type uses the trajectory- 
based speed control law prior to the ABP, and a state-based speed control law after the 
ABP. The ABP and PTP for the CROSS clearance can be specified as the same 
waypoint or different waypoints. 


For the CAPTURE clearance type, the objective is to capture the spacing goal at or 
greater than a minimum closure rate, then maintain the spacing interval to the PTP. 
Because both airplanes are on the same route, knowledge of the target airplane’s 
trajectory is not required. Therefore the state-based speed control law is used 
throughout the operation. 


For the MAINTAIN clearance type, the objective is to maintain the initial spacing interval 
between the FIM-S and target airplane until PTP. Both airplanes are on the same route, 
the target’s trajectory is not required, and state-based speed control law is used. This is 
the only FIM-S operation where the spacing goal is not provided by the air traffic 
controller. 
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Table 1. ATD-1 FIM-S Flight Test Matrix 


Tgt Delay | FIM1 Clinc FIM1 FIM1 FIM1 FIM2 Clnc FIM2 FIM2 FIM2 
Scenario Tgt Route (see TgtRts) Type FIM1 T/D FIM1 Route SpErr ABP PTP Type FIM2 T/D FIM2 Route SpErr ABP PTP 
Al enroute 0 (.78M) CROSS Time en route +20sec JELVO MAHTA CROSS Time en route -15 sec JELVO MAHTA 
A2 en route 0 (.78M) CROSS Distance en route +3 NM JELVO MAHTA CROSS Distance en route -2 NM JELVO MAHTA 
A3 en route 0 (.78M) CAPTURE Time en route +20 sec na JELVO CAPTURE Time en route -15 sec na JELVO 
A4 en route 0 (.78M) CAPTURE Distance en route +3 NM na JELVO CAPTURE Distance enroute -2 NM na JELVO 
AS en route 0 (.78M) MAINTAIN Time en route na na JELVO | MAINTAIN Time enroute na na JELVO 
A6 en route 0 (.78M) MAINTAIN Distance en route na na JELVO | MAINTAIN Distance en route na na JELVO 
B1 JELVO.SUBDY No Delay CROSS Time ZIRAN.SUBDY " -20 NALTE FAF CAPTURE Time ZIRAN.SUBDY "+30 na FAF 
B2 ZIRAN.SUBDY No Delay CROSS Time JELVO.SUBDY (6) PTP FAF MAINTAIN Time JELVO.SUBDY na na FAF 
B3 ZIRAN.SUBDY No Delay CROSS Time JELVO.SUBDY ” +60 PTP FAF CROSS Time TRAKX.UPBOB ” +30 PTP FAF 
B4 JELVO.SUBDY No Delay CAPTURE Time JELVO.SUBDY ” -60 na FAF MAINTAIN Time JELVO.SUBDY na na FAF 
BS JELVO.SUBDY No Delay CAPTURE Time JELVO.SUBDY ” +60 na FAF CROSS Time TRAKX.UPBOB ” +30 PTP FAF 
B6 JELVO.SUBDY No Delay | MAINTAIN Time JELVO.SUBDY na na FAF CROSS Time ZIRAN.SUBDY " +15 NALTE FAF 
B7 JELVO.SUBDY Med Delay CROSS Time ZIRAN.SUBDY "  -20 NALTE FAF CAPTURE Time ZIRAN.SUBDY ” +30 na FAF 
B8 ZIRAN.SUBDY Med Delay CROSS Time JELVO.SUBDY e) PTP FAF MAINTAIN Time JELVO.SUBDY na na FAF 
B9 ZIRAN.SUBDY Med Delay CROSS Time JELVO.SUBDY ” +60 PTP FAF CROSS Time TRAKX.UPBOB ” +30 PTP FAF 
B10 JELVO.SUBDY Med Delay | CAPTURE Time JELVO.SUBDY " -60 na FAF MAINTAIN Time JELVO.SUBDY na na FAF 
B11 JELVO.SUBDY Med Delay | CAPTURE Time JELVO.SUBDY ” +60 na FAF CROSS Time TRAKX.UPBOB ” +30 PTP FAF 
B12 JELVO.SUBDY Med Delay | MAINTAIN Time JELVO.SUBDY na na FAF CROSS Time ZIRAN.SUBDY ” +15 NALTE FAF 
B13 JELVO.SUBDY High Delay CROSS Time ZIRAN.SUBDY ~ -20 NALTE FAF CAPTURE Time ZIRAN.SUBDY "+30 na FAF 
B14 ZIRAN.SUBDY _ High Delay CROSS Time JELVO.SUBDY (6) PTP FAF MAINTAIN Time JELVO.SUBDY na na FAF 
B15 ZIRAN.SUBDY High Delay CROSS Time JELVO.SUBDY ” +60 PTP FAF CROSS Time TRAKX.UPBOB ” +30 PTP FAF 
B16 JELVO.SUBDY High Delay | CAPTURE Time JELVO.SUBDY ” -60 na FAF MAINTAIN Time JELVO.SUBDY na na FAF 
B17 JELVO.SUBDY High Delay | CAPTURE Time JELVO.SUBDY ” +60 na FAF CROSS Time TRAKX.UPBOB ” +30 PTP FAF 
B18 JELVO.SUBDY High Delay | MAINTAIN Time JELVO.SUBDY na na FAF CROSS Time ZIRAN.SUBDY " +15 NALTE FAF 
B19 ZIRAN.SUBDY No Delay CROSS Time JELVO.SUBDY " +20 NALTE FAF CROSS Time ZIRAN.SUBDY ” +15 NALTE FAF 
B20 ZIRAN.SUBDY Med Delay CROSS Time JELVO.SUBDY ” +20 NALTE FAF CROSS Time ZIRAN.SUBDY ” +15 NALTE FAF 
B21 ZIRAN.SUBDY High Delay CROSS Time JELVO.SUBDY ” +20 NALTE FAF CROSS Time ZIRAN.SUBDY ” +15 NALTE FAF 
B22 ZIRAN.SUBDY No Delay CROSS Distance JELVO.SUBDY +2 nm PTP FAF CROSS Distance ZIRAN.SUBDY +1 nm PTP FAF 
B23 ZIRAN.SUBDY Med Delay CROSS Distance JELVO.SUBDY +2 nm PTP FAF CROSS Distance ZIRAN.SUBDY +1 nm PTP FAF 
B24 ZIRAN.SUBDY __ High Delay CROSS Distance JELVO.SUBDY +2 nm PTP FAF CROSS Distance ZIRAN.SUBDY +1 nm PTP FAF 
C1 Str-in No Delay FINAL Time Str-in +15 sec PTP 6.25 
C2 Str-in No Delay FINAL Distance Str-in +1 NM PTP 6.25 
C3 Str-in No Delay FINAL Time Turn +15 sec PTP 6.25 
C4 Str-in No Delay FINAL Distance Turn +1 NM PTP 6.25 
cs Turn No Delay FINAL Time Str-in +15 sec PTP 6.25 
C6 Turn No Delay FINAL Distance Str-in +1NM PTP 6.25 
C7 Str-in High Delay FINAL Distance Turn +1NM PTP 6.25 
C8 Turn High Delay FINAL Distance Str-in +1NM PTP 6.25 
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The SPACE clearance type is a special subset of the CROSS operation. It is designed 
to be initiated within TRACON airspace. To use trajectory-based control laws, the FIM-S 
avionics make assumptions when determining FIM-S and target trajectories, and the 
PTP is defined as 6.25 nmi from the runway threshold. The SPACE clearance type can 
begin when one airplane is established on final and the other airplane is also established 
on final or on a vector less than 45 degrees to the final course. 


The tests have been designed to evaluate FIM-S system performance while allowing the 
test conditions variables that affect the operation and its performance to be isolated as 
much as possible so that their effects can be assessed individually. It is not possible to 
control some of the variables (e.g., effects of wind vector, latency in crew response to 
speed guidance) and, because there are many independent variables, total isolation was 
not expected. Therefore the distribution of combinations of variables in Table 1 allowed 
close examination of the target delay, type of algorithm (trajectory-based or constant- 
time delay), and early and late ABP placement. The structure of test scenarios is 
organized to examine the following independent variables: 


e Spacing error (airplane position relative to the location desired by the schedule) 
e Spacing type (time in seconds or distance in tenths of nautical miles) 

e Lead airplane delay (none, medium, or high; speed aligned to ground schedule) 
e ABP location (merge point or final approach fix) 

e Airplane route geometry (for the Final Approach Scenario only) 


Based on this design, the definition of delay is a positive value that indicates the IM 
operation aims for the airplane to speed up (decrease spacing); a negative value aims 
for the airplane to slow-down (increase spacing). Further detailed variable definitions can 
be found in the Post-Flight Data Analysis report [14]. 


3.2 Arrival and Approach Procedures Design 


The flight test WG leaders along with the Air Traffic Facilities involved designed the 
arrival and instrument approach procedures with considerable help from Jeppesen, Inc., 
FAA, ANM-200, AFS-460 and United Airlines who completed the Simulator Validation 
Flights in their 737 full motion simulator. The instrument approach procedures depicted 
in the approach plates were released for the public and published as procedures for both 
runways 32R and 14L at Moses Lake. RNAV (RNP) Z AR approaches were selected 
because they contain RF legs which will satisfy testing requirements of the FIM-S 
system algorithm. 


Figure 11 is an example flight test run where the operations overlay the map of the 
procedures. The Honeywell Dassault Falcon 900 is shown as the red icon in the center 
(N889H); the Honeywell Boeing 757 is shown as the black icon at the right (NWH) and 
the United 737 is shown as a red icon at the left (UAL2197). This was a low altitude test 
case started at flight level 230 with merging at NALTE and the PTP at ZAVYO. The 757 
was assigned a CROSS clearance with the Falcon 900 as the target; the 737 was 
assigned a CROSS clearance with the 757 as the target: NALTE had been the ABP for 
both FIM-S airplanes. 
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Figure 11. Example FIM-S Operations and Arrival and Approach Procedures 


The arrival procedures had been developed by the NASA ATD-1 P2 team. The 
procedures have many of the features found in recently implemented arrival procedures 
at busy airports in the US in that they have speed and altitude constraints at a number of 
the defining waypoints. The FIM-S system requires these constraints to define the 
vertical and speed profiles for both target and executing airplanes. Because the flight 
tests were carried out under IFR, the procedures were subjected to normal development 
and approval processes, and were published as Special procedures for use only by 
Honeywell and United Airlines during tests. 


The SUBDY RNAV STAR has en-route transitions (ZIRAN and JELVO start points) 
converging from west and east and thus providing arrival direction diversity allowing 
examination of the differing effects of wind components. The transitions merge at 
waypoint NALTE at 17,000 ft. msl., provide opportunity for a merge between traffic 
streams part-way down the descent, but with control space to allow correction of initial 
spacing error from both high altitude initiations (FL350) and medium altitude initiations 
(FL230). The STAR terminates at SUBDY, which is also a transition waypoint to the 
RNAV (RNP) Z AR approach to Moses Lake runway 32R. 


The NALTE RNAV STAR is similar to the SUBDY STAR in form and function. The STAR 
terminates at NALTE, a common initial point with an approach transition to the RNAV 
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(RNP) Z AR instrument approach to Moses Lake runway 14L. (Note: only the STARs 
and IAPs to runway 32 were flown during the flight test.) 


The UPBOB RNAV STAR provides more arrival direction diversity by bringing the user 
to Moses Lake from the southeast. The STAR terminates at UPBOB, a common initial 
point with approach transitions to the RNAV (RNP) Z AR instrument approaches to 
Moses Lake runways 32R and 14L. 


All STARs, therefore, provide simple linking between arrival and approach procedures 
as needed by the FIM-S system functions. When selecting the procedures in the FMS 
per flight test card instructions, see the flight test plan for more detail [11], flight crews 
will close any discontinuities ensuring that all procedure points remain. 


3.3 Data Collection 


The Data Collection and Analysis WG started its work by tracing the requirements in the 
NASA FIMSRD, SOW and Boeing SRDD to the corresponding airplanes participating in 
the flight test and their respective recording systems. NASA submitted to the Data 
Analysis WG a data request list in early summer 2016 from which to record and deliver 
flight test data and IM performance metrics in the SOW. This NASA document became 
the basis for data recording requirements and traceability to recording systems, 
procedures and data artifacts provided in Appendix C of the Flight Test Plan. 


Data collection was performed on-board the airplane using the following systems: 


e FB recording system: 


o All FIM-S system parameters, including HMI entries, airplane states 
(ownship and traffic), trajectories, and control system details. 


e TPU recording system: 


o All TPU system data used during flight test to troubleshoot some issues. 
None of the TPU data was used as a primary source for computing IM 
Performance data and analysis based thereupon. 


e Airplane recording system: 


co Airplane parameters, including airplane state, configuration, and fuel. 
FMS lateral and vertical deviations where available. 


o Private systems on-board 757 and F900, and flight data recorder in the 
737. 


Video recordings of the cockpit environment and EFBs were collected on the 757 and 
used during flight test to troubleshoot some HMI and other system issues. The videos 
were not otherwise used and were delivered directly to NASA from Honeywell on 
conclusion of each flight. 


All sources of data included GPS-sourced, UTC timestamps for data correlation. The 
process for collecting and delivering data under the flight test program is depicted in 
Figure 12. EFB and TPU data was available daily during post-flight for analysis and 
troubleshooting, per flight condition. Airplane data was available within 24 hours and not 
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Figure 12. FIM Flight Test Program Data Flow 


used directly during flight test but was the primary source for some of the data analysis 
(e.g. fuel, lead airplane airspeed). 


Raw data from all systems on all airplanes are archived in a Flight Test Data Repository. 
Daily handoff of the data to NASA occurred during flight test. The entire set of raw data 
collected makes up Deliverable D4.24 and was delivered to NASA on March 29, 2017. 


The data set considered consists of data collected on three airplanes during the flight 
test conducted Jan 20-Feb 22 2017 in the Seattle area. For more details about the flight 
test and data collected consult the Flight Test Plan document. The dataset contains data 
for a total of 19 flying days and 198 unique FIM-S operations flown. 


The Flight Test Data was delivered under Deliverable 4.24 on March 29, 2017. An 
accompanying document on the delivered physical media describes the form of the data, 
and Appendix C of the Flight Test Plan describes its content. 
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3.4 Data Analysis 


The first task in data analysis was to define and derive the IM Performance data from the 
raw flight test data collected. A total of 34 metrics were derived from the Flight Test 
Data, for each of the analyzed conditions. They fall in the following categories: 


e IM Operation Performance, including initial conditions (initial spacing error, 
altitude and airplane state), and key system performance: 


o PTP delivery performance 

o ABP delivery performance 

o FIM Speed issue performance 
e Winds observed and forecast 
e Fuel burn 


e Flight Technical Error, from FMS deviations where available. 


Approximately 11% of the experiments were discarded due to bad or unusable data for a 
variety of reasons that include operator error, software errors, and scenario setup 
difficulties. Of the good data, 80% was retained for performance and other analysis 
reported herein; the remainder (9%) was flagged for further study to investigate system 
behavior deemed incorrect or not fully understood. The data set used for this analysis 
report consists of 144 flown FIM-S experiments (runs): 11 en-route (A conditions) 
experiments, 8 final approach spacing experiments and 125 arrival/descent experiments 
(B conditions). The data set includes 75 conditions for the 757 and 69 conditions for the 
737. Of the four clearance types the prototype FIM-S system can handle, the data set 
contains 25 MAINTAIN, 36 CAPTURE, 75 CROSS, and 8 SPACE operations. Fifteen 
(15) of the operations were done using a distance-based spacing goal and 129 using a 
time-based spacing goal. 


The summary statistics for each category of IM operation is shown in a series of figures 
(Figure 13 through Figure 24) using box plots, spanning from the general (e.g., all time- 
based operations) to the specific (e.g., time-based CROSS operations with ABP at 
NALTE). Box plots are standardized statistic graphical representation of slices of the 
data set depicting the median, lower, and upper quartiles and outliers for each metric. 
Boxplots are shown only for slices of the experiment matrix with sample size of seven or 
more. Below each boxplot (when shown) is a table with the full data. Note that the 
standard deviation is not included in each table as the data is not necessarily normally 
distributed and use of the standard deviation is typically tied to analyses that assume 
normality. 


Displayed measures of performance computed from the raw set include: 


e Initial Spacing Error (seconds [s] or nmi): Spacing error at beginning of FIM-S 
operation 
e PTP achieved spacing error (s or nmi) 


e ABP achieved spacing error (s or nmi) [CROSS operations only] 
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Time Based Metrics (s) 


All Time Based Clearances: 129 
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Figure 13. IM Performance - All Time-Based Clearances 


ABP achieved spacing error (s or nmi) [CROSS operations only] 

Number of IM speeds issued (NumSpeeds) 

Number of IM speeds issued per minute of IM operation (NumSpeeds_rate) 
Pilot implementation time (MCP time) — mean and standard deviation 

Time to capture (minutes) [CAPTURE operations only] 


RMS error of maintain segment (s) 


More information on the definition and computation for each metric can be found in the 
Post-Flight Analysis Report (D4.26). 
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All Distance Based Clearances: 15 


-4 | 
[ [ [ [ [ 
Initial error PTP error Num Speeds NumSpeeds_rate MCP time (mean) MCP time (std) 
InitialSpacing IM Length PTP error numSpeeds_ numSpeeds_GS_S pilotTime_mean _pilotTime_std 
Error (nm) (nm) (nm) numSpeeds perMin egment (s) (s) 

Mean 0.19 46.13 0.18 5.80 0.77 2.07 7.71 2.68 
95% Cl low -1.09 29.47 -0.27 3.67 0.55 1.03 6.06 1.71 
95% Cl high 1.47 62.79 0.62 7.93 0.99 3.10 9.37 3.66 
Range 7.89 84.80 2.39 13.00 1.34 6.00 12.25 6.70 
IQR 3.55 56.08 0.80 5.75 0.40 2.75 2.46 1.93 


Figure 14. IM Performance - All Distance-Based Clearances 
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Time Based Metrics (s) 


All Time-Based MAINTAIN Clearances: 22 
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Figure 15. IM Performance - Time-Based MAINTAIN 
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All Time-Based CAPTURE Clearances: 34 
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Error (s) (nm) PTP error(s) numSpeeds perMin (s) pilotTime_std (s) _RMS (s) tCapture (s) 
Mean -6.58 88.35 0.19 10.47 0.54 10.03 8.93 3.91 334.06 
95% Cl low -21.99 80.90 -0.81 8.89 0.48 8.37 5.84 3.29 260.69 
95% Cl high 8.82 95.80 1.18 12.05 0.60 11.69 12.02 4.52 407.43 
Range 127.95 79.75 13.60 17.00 0.69 20.93 32.16 6.91 1047.00 
IQR 73.83 22.60 2.59 7.00 0.25 6.10 8.13 1.81 223.00 
Figure 16. IM Performance - Time-Based CAPTURE 
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Time Based Metrics (s) 


All Time-Based CROSS Clearances: 68 
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Initial error PTP error ABP error MaintaintSegmentErrorRMS Num Speeds NumSpeeds_rate MCP time (rms) MCP time (std) 
InitialSpacing IM Length numSpeeds_per pilotTime_mean_ pilotTime_std MaintainError_ 
Error (s) (nm) PTP error(s) ABP error(s) numSpeeds Min (s) (s) RMS (s) 
Mean -17.49 83.27 3.49 3.24 9.78 0.53 8.13 5.08 3.84 
95% Cl low -25.22 79.56 Al 7A 1.16 8.91 0.48 7.38 3.45 3.00 
95% Cl high -9.77 86.99 5.27 5.32 10.65 0.57 8.87 6.71 4.68 
Range 180.00 72.49 34.22 38.25 16.00 0.80 16.20 41.05 7.80 
IQR 34.63 18.67 7.82 10.87 5.00 0.22 2.94 2.94 2.82 
Figure 17. IM Performance - Time-Based CROSS 
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All Time-Based CROSS Clearances (ZAVYO): 41 
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Error (s) (nm) PTP error(s) ABPerror(s) numSpeeds Min (s) (s) 
Mean -15.69 78.56 6.20 6.20 8.07 0.45 8.14 4.99 
95% Cl low -27.58 74.19 3.60 3.60 7.18 0.40 7.17 3.04 
95% Cl high -3.80 82.93 8.80 8.80 8.97 0.50 9.11 6.93 
Range 180.00 59.29 34.22 34.22 12.00 0.80 16.20 38.14 
IQR 41.53 15.98 11.78 11.78 3.00 0.19 2.88 2.58 


Figure 18. IM Performance — Time-Based CROSS (ABP at ZAVYO) 
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Time Based Metrics (s) 
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All Time-Based CROSS Clearances (NALTE): 27 
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Initial error PTP error ABP error MaintaintSegmentErrorRMS Num Speeds NumSpeeds_rate MCP time (rms) MCP time (std) 
InitialSpacing IM Length numSpeeds_per pilotTime_mean_ pilotTime_std MaintainError_ 
Error (s) (nm) PTP error(s) ABP error(s) numSpeeds Min (s) (s) RMS (s) 
Mean -20.22 90.43 -0.63 -1.63 12.37 0.64 8.11 5.23 3.84 
95% Cl low -28.41 84.53 -1.50 -4.27 11.14 0.58 6.88 eo 3.00 
95% Cl high -12.04 96.33 0.25 1.02 13.60 0.69 9.33 8.25 4.68 
Range 94.98 60.17 8.26 29.57 12.00 0.58 14.21 40.07 7.80 
IQR 20.60 23.47 3.16 7.32 3.75 0.19 3.14 3.42 2.82 
Figure 19. IM Performance - Time-Based CROSS (ABP at NALTE) 
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InitialSpacing IM Length numSpeeds_ per pilotTime_mean_pilotTime_std 
Error (s) (nm) PTP error(s) ABPerror(s) numSpeeds Min (s) (s) 
Mean -10.62 21.16 3.37 3.37 5.00 0.84 7.20 3.14 
95% Cl low -38.44 12.62 -1.33 -1.33 3.76 0.42 -0.87 -2.88 
95% Cl high 17.19 29.69 8.08 8.08 6.24 1.27 15.27 9.16 
Range 52.46 17.97 9.90 9.90 2.00 0.88 17.00 11.75 
IQR 17.77 8.07 5.15 5,15 2.00 0.28 8.75 3.35 
Figure 20. IM Performance - Time-Based SPACE (5 samples) 
InitialSpacing IM Length PTP error numSpeeds__ pilotTime_mean MaintainError 
Error (nm) (nm) (nm) numSpeeds perMin (s) pilotTime_std (s) _RMSS (s) 
Mean 0.07 30.11 -0.31 2.67 0.90 6.78 0.96 0.14 
95% Cl low -0.09 4.59 -1.01 -1.13 -0.76 0.45 -1.23 0.10 
95% Cl high 0.23 55.63 0.40 6.46 2.57 13.10 3.15 0.18 
Range 0.12 18.84 0.50 3.00 1.34 5.00 1.73 0.03 
IQR 0.09 14.13 0.38 2.25 1.00 3.75 1.30 0.03 
Figure 21. IM Performance - Distance-Based MAINTAIN (Three samples, all A scenarios) 
InitialSpacing IM Length PTP error numSpeeds__ pilotTime_mean MaintainError 
Error (nm) (nm) (nm) numSpeeds perMin (s) pilotTime_std (s) _RMS (s) tCapture (s) 
Mean -0.62 31.09 0.52 3.00 0.73 10.37 3.70 9.52 285.00 
95% Cl low -41.17 -24.20 -12.96 -9.71 -0.14 -38.86 -34.38 
95% Cl high 39.94 86.38 13.99 15.71 1.61 59.61 41.79 
Range 6.38 8.70 2.12 2.00 0.14 7.75 3)\8)8) 0.00 0.00 
1QR 6.38 8.70 2.12 2.00 0.14 7.75 5.99 0.00 0.00 
Figure 22. IM Performance - Distance-Based CAPTURE (Two samples, all A scenarios) 
InitialSpacing IM Length PTP error ABP error numSpeeds per pilotTime_mean_pilotTime_std 
Error (nm) (nm) (nm) (nm) numSpeeds Min (s) (s) 
Mean 0.91 72.75 0.32 0.32 9.14 0.59 8.38 3.29 
95% Cl low -1.62 54.51 -0.55 -0.55 6.45 0.41 6.69 2.18 
95% Cl high 3.45 90.99 1.18 1.18 11.84 0.77 10.06 4.41 
Range 6.95 59.52 2.38 2.38 9.00 0.57 4.53 3.39 
IQR 4.73 20.28 1.67 1.67 3.50 0.27 2.74 1.75 
Figure 23. IM Performance - Distance-Based CROSS (Seven samples, all B scenarios) 
InitialSpacing IM Length PTP error ABP error numSpeeds_per pilotTime_mean_pilotTime_std 
Error (nm) (nm) (nm) (nm) numSpeeds Min (s) (s) 
Mean -0.84 10.06 0.09 0.09 3.00 1.08 5.33 2.30 
95% Cl low -2.61 5.96 -0.49 -0.49 0.52 -0.17 -3.39 0.39 
95% Cl high 0.94 14.16 0.68 0.68 5.48 2.33 14.06 4.21 
Range 1.43 3.06 0.45 0.45 2.00 0.98 7.00 1.41 
IQR 1.07 2.30 0.34 0.34 1.50 0.74 5.25 1.06 


Figure 24. IM Performance - Distance-Based SPACE (Five samples) 


When taken in aggregate, time-based operations delivered at the PTP slightly worse 
than the MOPS criterion of 10s of error at 95%. The empirical probability of an error less 
than 10s is 88.3%; the detailed descriptions are found in the Post-flight Data Analysis 
Report [14] under the summary and conclusions section as well as the discussions 
related to Figure 13. This is mostly driven by CROSS operations, which in aggregate 
have a probability of delivering less than 10s of error at the PTP of 78%, whereas no 
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instances of errors greater than 10s were seen for MAINTAIN, SPACE or CAPTURE 
operations. 


The slightly worse PTP performance of CROSS operations has been attributed to 
instances with a late merge including the UPBOB route for the trail airplane. Executions 
of CROSS operations with an upstream merge have significantly better performance. It 
is believed that a different design for the UPBOB1 STAR, with a better-matched nominal 
altitude and speed profile would eliminate the observed poorer performance. A different 
design for the UPBOB1 STAR was drafted and a few operations were performed to 
enable comparisons, but this fell outside the scope of the contractor’s analysis. As a 
general conclusion from the observed data, it would seem that better PTP performance 
for CROSS operations should be sought operationally by placing the ABP upstream of 
the PTP, at or downstream of route merges, thereby creating a maintain segment. Route 
design with late merges near the PTP are not conducive to good PTP delivery 
performance. 


Similar effects are observed at the ABP. Overall, time-based CROSS operations have 
an empirical probability of ABP errors of less than 10s of only 69%. However, operations 
with the ABP at NALTE have 78% observed errors below 10s, and when excluding a 
number of conditions where the operation started with insufficient control authority 
(distance to ABP too short for the initial spacing error), that probability increases to 88%. 
It is believed that with better design of the nominal altitude and speed profile at NALTE 
for both the ZIRAN and JELVO transitions of the SUBDY1 STAR the ABP performance 
would meet the MOPS criterion. 


Maintain segment performance for MAINTAIN, CAPTURE and CROSS (NALTE) 
operations has a mean of 3.6s using the RMS error metric. Although the MOPS does not 
define maintain performance in this way, it is believed that in aggregate the flight test 
demonstrated acceptable maintain performance. 


Thirty of the 34 (88%) CAPTURE operations had capture rates better than the MOPS 
criteria of 3s per minute. The majority of the cases that did not meet this level of 
performance are attributed to extreme cases at the back of the chain with medium to 
large delay at the front of the chain. 


This level of overall performance is achieved with an average rate of 0.57 IM speeds per 
minute (one IM speed command every 2 minutes). Pilots have nominally indicated in 
surveys that the number of IM speeds was acceptable, but it has been observed that 
MAINTAIN operations tend to issue more speeds than other clearances, as well as 
include more reversions. This has been attributed to the design of the CTD algorithm 
and the lack of hysteresis in cases where the speed error is near the discretized speed 
action threshold. 


This performance is achieved through a wide variety of initial spacing errors (96s too 
close to 84s too late) on three different routes, for descent, cruise and final approach 
operations, two different airplanes, and 19 different days of experienced wind conditions 
(from 61 kt of average headwind to 67 kt of average tailwind) and associated forecasts 
and errors (from 2 kt to 19 kt of average RMS along-track forecast error). 
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Figure 25. Along Track Wind Forecast Error 


Wind forecast errors for each flight day is reported in Figure 25. The metric used is the 
Along-Track Wind Forecast Error (ATWFE) which is the wind forecast error (forecast — 


truth) laid against the track in RMS aggregate. 


The along track wind forecast error analysis revealed a large variation of forecast errors 
throughout the 19 flight days. In general, the forecast error tended to go through a large 
variation near the RF turns on the SUBDY procedure. This is expected because the 

forecasts were generated from a column of air over the Grant County airport for the low 
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altitude forecast breakpoints (surface, 6,000 ft, and 12,000 ft) and the trajectory 
geometry changes direction significantly through the RF turns in the 6,000 ft to 12,000 ft 
altitude band. A correlation analysis between the PTP delivery performance and IM 
speed rate reveals very low correlation between ATWFE and performance. 


The Fuel Burn analysis performed only compared fuel burn across operations in the 
flight test and have no comparative basis to a non-FIM OPD operation. In general, the 
analysis revealed expected differences between airplane types and correlated to the 
number of FIM speeds issued. The descriptive statistics for the fuel burn are shown in 
Figure 26. 
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Figure 26. Average Fuel Burn Rate by Operation 


The PDE analysis performed revealed overall small values for PDE, including less than 
2000ft average vertical difference among the descent paths between the FMS and FIM- 
S computed vertical trajectories. This is an excellent result given the difference in fidelity 
of the two system trajectory generators. 
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4 Lessons Learned, Conclusions, and 
Recommendations 


This section documents the issues and organizes them into lessons learned, 
conclusions, and recommendations. It is the hope that they will guide the stakeholders 
as they contemplate the next step in further development efforts. The subsections 
reference the design and evaluation activities as well as flight test activities described in 
sections 2 and 3. 


4.1 Lessons Learned 


The following list is organized by areas of potential impact on future design and testing 
steps. Included is the full text from written comment requests submitted by individual 
team members that participated in the flight test. When individuals submitted comments, 
they were preceded by the name of the organization authoring the comment and 
numbered C3 — C47. Some comments (without the organization name) are findings from 
the WG team members representing several team member organizations (e.g., C1, C2, 
etc.) Summary recommendations in section 4.3 are derived from the significant 
comments listed, and include references to help trace to the paragraph content. 


4.1.1. Minimum Operational Performance and Other Standards 
Displays/Human Machine Interface 


Basic airborne situation awareness display (AIRB) is a prerequisite for all airborne 
surveillance applications, including FIM-S. The CDTI used in this demonstration came 
from a system that had been certified for AIRB per DO-317A. A regression analysis was 
performed against the current MOPS (DO-317B) and it was determined there were no 
significant differences between the standards for CDTI that would impact performance 
during the demonstration. 


Other aspects of the HMI, in particular the FIM-S data entry screens and FIM-S outputs, 
including speed commands and annunciations, were developed from previous NASA 
work on FIM [8]. The final implementation was then checked for compliance with the FIM 
MOPS. While there was extensive discussion in the HMI WG leading up to the final HMI 
design, there was not enough time to conduct pilot focus group reviews and usability 
studies typically used to verify certified avionics equipment. Therefore, the HMI used in 
this demonstration should be considered minimally compliant to the MOPS but not 
optimized for cockpit use (e.g., minimizing crew workload) 


Algorithms 
The primary speed control algorithms for FIM-S in this demonstration came from NASA's 


Airborne Spacing for Terminal Arrival Routes version 13 (ASTAR13) 7th Revision [4]. 
ASTAR compliance to the FIM MOPS (DO-361) was assumed based on previous NASA 
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work. Other algorithms, such as final approach spacing and conformance monitoring 
were developed to meet the FIM MOPS? requirements. 


Because of the compressed schedule and testing risks, the complete suite of FIM MOPS 
verification tests were not performed as part of this demonstration; however, basic speed 
control performance was checked using a subset of the MOPS tests. The results of 
these tests are included in Table 2. See the System Test Plan [10] for details on the rest 
of the system verification that was performed. 


Table 2 summarizes the subset of MOPS performance tests that were run against the 
FIM-S software developed for this project. The pass/fail criteria in this table are from the 
MOPS, however as described in the system test plan, this project had less stringent 
pass/fail criteria for the system tests based on the assumption that the ASTAR algorithm 
was fully tested in previous work at NASA. Except for the final approach spacing 
clearance which was not extensively tested at NASA for ASTAR13 that assumption 
appears to be valid. 


Based on these results presented at SAR, the demonstration implementation of 
ASTAR13 performance was deemed acceptable for flight test. Further investigation of 
the algorithms performance on distance-based final approach spacing clearances is 
warranted however, as well as more validation of the MOPS test vectors for this 
clearance. 


FIM MOPS Requirements Observations 


The NASA System Requirements Document (NASA FIMSRD) [8] included directly or by 
reference the FIM MOPS requirements as they existed at the time the NASA FIMSRD 
was released. The FIMSRD was extensively reviewed at the start of the program by the 
entire SE team. This review included engineers, managers and pilots drawn from all the 
participating organizations — NASA, FAA, Boeing, Honeywell and United. The results of 
this review were captured in the NASA FIMSRD revision 3.1, released on August 27, 
2015. 


The NASA FIMSRD revision includes a notation on each MOPS requirement considered 
for this project indicating if the requirement was accepted as-is, modified or deleted. The 
details captured in the SRD will not be repeated here, however the highlights of 
differences/findings are listed below: 


. Aural alerting was not implemented for this demonstration. 
IM Turn was not implemented for this demonstration. 


1 
2 
3. IM Procedural Limit requirements were modified/added compared to the MOPS. 
4 


Departure Intended Flight Path Information (IFPI — SID, SID En Route Transition) 
were not implemented. This is a MOPS requirement, but current Concept of 
Operations (CONOPS) does not include departure operations. 


? Because this project started before RTCA DO-361 was released, compliance was ensured by 
including the relevant MOPS requirements from a mature draft of the MOPS directly into the 
project System Requirements Document, GFI 5.13. 
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Table 2. Speed Control Performance Test Summary 


CROSS ASG: 120s 


w/in 9.4s at own crossing passed at 4.17 vs. 9.4s 
initial spacing: 37s 


maintain w/in 9.4s of ASG > 95% passed at 100% 


distance ASG: 3 NM w/in 9.4s * own nom ground speed at Traffic To passed at 0.05 vs. 0.485 NM 
initial spacing: 2 NM Follow (TTF) crossing 


maintain w/in 9.4 * (max ground speed) > 95% passed at 100% 


time JET1 ASG: 160s capture phase: @3s/min pass 
initial spacing: 123s 
Se maintain w/in 9.4s of ASG > 95% pass at 100% 


JET6 ASG: 90s capture phase: @3s/min pass 


initial spacing: 120s 
maintain w/in 9.4s of ASG > 95% passed at 100% 


JET1 ASG: 7.5 NM capture @ 0.125 NM/min pass 
initial spacing: 5.35 NM 


maintain w/in 9.4 * (max ground speed) > 95% pass at 100% 


JET6 ASG: 7.5 NM capture @ 0.125 NM/min pass 
initial spacing: 5.32 NM 
[Se 


maintain w/in 9.4 * (max ground speed) > 95% fail at 94.84% 


eee 
time test1 ASG: 120s w/in 9.4s at own crossing passed at 0.68 vs. 9.4s (but at last 
ee La spacing 1025 | 
initial spacing: 156s moment) 
initial spacing: 82s moment) 


distance test2 ASG: 5 NM wiin 9.4s * own nom ground speed at TTF crossing failed at ~60% over tolerance 
initial spacing: 11.17 
NM 


time 


CAPTURE 


distance 


SPACE 


initial spacing: 9.35 NM 
ASG: 5 NM 
initial spacing: 4.57 NM 
MAINTAIN 


failed at ~35% over tolerance 
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5. Additional requirements for wind/temperature processing were included. 


6. Speed control requirements were included by reference to the ASTAR 
description document [4]. 


7. Several “hard” requirements in the MOPS were made configurable in this 
implementation, including IM speed profile limits, conformance bounds, and 
ground speed matching. However, at the conclusion of system testing and SAR it 
was decided to use the standard MOPS values for each of these parameters in 
the flight test. 


8. Minimum Safe Speed monitoring (FRAC.235/236) was not implemented in the 
FIM-S equipment for this demonstration because all airplanes involved included 
this monitoring in other onboard systems. 


9. The IM feasibility check was not implemented. However an engineering display 
of anticipated Measured Spacing Interval (MSI)/Predicted Spacing Interval (PSI) 
and initial soeed command was implemented so that pilots and the flight test 
director could assess the feasibility of any given clearance during the flight test. 


10. The MOPS PI requirements were supplemented with requirements from the 
NASA HMI PI implementation [6]. 


11. The MOPS speed command indication requirements were supplemented with 
requirements from the NASA HMI fast/slow indicator implementation [6]. 


12. The CDTI state descriptions used in this implementation were based on the 
NASA HMI rather than the generic state descriptions in the MOPS. The detailed 
HMI requirements in MOPS section 2.3.5 and subsections were included in the 
SRD, however there were enough modifications to the requirements to match the 
NASA HMI that these MOPS requirements cannot be considered fully validated 
in this implementation. 


13. Additional requirements were provided for pre-populating and clearing selected 
clearance information. This was done both to improve the HMI for standard FIM- 
S operations as well as to support the specific conditions of flight test (e.g., 
performing multiple clearances in a row without landing/resetting the system 
between runs). 


In addition to the items listed, there were many requirements included in the NASA 
FIMSRD that were not related to MOPS requirements (tagged as “MOPS Status: New” 
in the FIMSRD). Most of these requirements were included to support this specific flight 
test program and should not be interpreted as indicating the MOPS were in any way 
incomplete. 


At the conclusion of the NASA FIMSRD review, all the requirements from the FIMSRD 
were captured in the System Requirements Definition Document (SRDD, deliverable 4.8 
[5]). This document was updated and maintained throughout the duration of the project. 
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As the detailed design and implementation proceeded it was found that some MOPS 
level requirements were problematic or required further clarification. These items were 
noted that could be reviewed for future updates to the MOPS: 


ie 


The default PTP (FRAC.024/025) requirements did not work out well for cruise 
operations. In the demonstration FIM-S equipment, all clearances included a 
destination airport (so the airplane could determine which direction the airplane 
was flying in cruise and to select which arrival and approach procedures to display 
for arrival operations) but this created a PTP and associated constraints that were 
not always appropriate. Cruise clearance IFPI requirements should be clarified 
based on real CONOPS scenarios. There was a similar problem with default 
altitude limits (FRAC.027) where inappropriate constraints could be generated 
depending on when the clearance was executed. 


. All requirements for FIM-S operation in the Mach regime were problematic. 


Because most of the previous work with ASTAR was in the arrival and approach 
phases, this was identified as a risk early in the program and although the design 
was extended to operate in the Mach regime, the resultant implementation should 
not be considered a complete Mach solution. Therefore, this project cannot be 
used to claim the Mach requirements in the MOPS have been validated. 


. Final Approach Spacing requirements were also problematic. This was another 


area where ASTAR13 had not been tested extensively and it was also identified 
as a risk early in the program. Requirements for this operation were developed in 
discussion in several WGs (HMI, Speed Control, and Flight Test) but the need for 
this much discussion would indicate the MOPS requirements in this area were 
also not fully developed. 


4.1.2 Procedures Design 


Boeing Comments 


C1. 


The set of arrival procedures used in this program were developed and 
designed exclusively to support the flight test program needs. The design was 
based on the needs of the flight test program, balanced with the airspace needs. 
The goal was to arrive at procedures that resemble modern Optimal Profile 
Descent (OPD) procedures in use throughout the NAS today. OPD procedures 
include altitude information to support “descend-via” operations but have little or 
no speed information. FIM-S operations require a smooth nominal speed profile 
embedded within the procedure design as the nominal basis for the control 
algorithm. 


Pilot feedback and data analysis revealed correlations between FIM performance 
and the nominal altitude and speed profile embodied in the design of each 
procedure flown in the flight test. Given that the route design establishes the 
baseline speed profile for the FIM-S system, a design that seeks smoother 
nominal speed transitions along the route would lead to less drastic speed 
changes during IM operations and a positive effect on performance. 


NEW 
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4.1.3 


System Engineering 


Boeing and Honeywell Comments 


C2. 


The SE tasks benefited from vital precursor activities performed prior to 
ATD-1 P2, yet faced the difficulty of managing a fixed software testing schedule 
from the start (i.e., two software release cycles). The precursor activities enabled 
the team to focus SE on the critical system level challenges within the conditions 
expected to be encountered during flight test at MWH. All ATD-1 concept of 
operations, architecture design tasks were performed prior to this contract and no 
refinements (e.g., integrated air-ground concept of operations SE analysis) were 
included in this already compressed detailed design phase for ATD-1 P2. 


The Boeing team members insisted on the firm allocation of all NASA 
requirements at the start of the program (i.e., prior to PDR). Once a stable set of 
requirements was agreed to, the ATD-1 P2 program could move ahead to PDR. 
This insistence on minimizing traveled risks (e.g., ASTAR implementation 
limitations — see Section 2.1) and managing scope risk issues, enabled thorough 
requirements understanding and reviews as well as accurate allocation of 
requirements to architecture elements. The use of formal configuration control 
tools and processes greatly enhanced communication and NASA, Boeing, 
Honeywell and United’s wiliness to collaborate. 


To enable accelerated testing yet test as much as possible within the detailed 
design phase, SE focused on minimizing traveled risks from implementation 
errors or omissions of the agreed PDR requirements. The team maintained 
traceability between initial design requirements, mapped implementation 
verification definitions, and test artifacts at the system level to minimize traveled 
risks and by relied on two precursors: 1) the previous NASA testing to ensure 
that ASTAR 13 met the MOPS performance requirements and 2) Honeywell’s 
ability to execute a subset of the MOPS performance tests on their hardware-in- 
the-loop test equipment to maintain the compressed schedule. 


Based on the results presented at SAR and the post-flight data analysis results, 
the implementation verification approach was deemed very successful. The 
prototype equipment was built without following all the processes of a fully 
certified development and test program. It is expected that the air navigation 
services provider (ANSP) and their certifying authorities will want to use these 
lessons learned to further guide testing of a FIM-S system that can be integrated 
with ground system capabilities (e.g., GIM, TBFM). The approach used in the 
program should allow them to follow similar risk reduction processes to integrate 
air and ground capabilities while in parallel test these components separately 
using industry standards and processes (e.g., DO-178C) in their respective 
implementations. 
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United Airlines’ Comments 


C3. Final [hardware]’ design needs to be completed/frozen much earlier in the 
process to better meet airline engineering and installation timeframes. Changes 
were still being [exchanged between United and] Boeing while the airplane was 
being modified. 


C4. The format/type of design documents also needs to be reviewed and 
agreed on during the contracting phase. Boeing did not provide the type of 
documents (service bulletins, etc.) that United’s engineers are used to receiving 
from Boeing/Airbus/vendors [for in-production systems]. This caused additional 
work for both United and Boeing. 


3 Editorial comments by the final report author to clarify lessons learned comments submitted by 
individual team members that participated in the flight test. 
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4.1.4 Operational Use 
United Airlines’ Comments 


C5. The FIM-S algorithm should not cause the number of airspeed changes 
as we experienced during the flight test. 


C6. FIM-S algorithm should not permit airspeed changes of 30-50 knots near 
the FAF like we experienced during the flight test. This causes large airplane 
configuration changes in a short period of time. It may also cause the airplane to 
be outside of the +75 ft. vertical profile required inside the FAF to fly a RNP 
approach. 


C7. The speed commands given by the FIM-S algorithm, especially when 
within 10 miles of the termination point, need to be smaller (100-knot speed 
reductions are not acceptable). 


C8. FIM-S algorithm will need to consider different airplane type speed 
requirements (e.g., 737-900 flies higher approach speeds when compared to a 
757 or an A320). 


C9. The FIM-S algorithm needs to take more account of the energy profile 
being flown; the airplane can’t be expected to descend and slow down at the 
same time. 


C10. For something like FIM-S to be able to be considered for airlines in the 
future, it would need to be able to be run on the airline’s existing EFBs (in 
United’s case it is iPads). United is not going to install a permanent EFB with 
FIM-S if we already have EFBs. This should be considered when developing the 
hardware and software. It would have been much more time and cost effective if 
we could have installed FIM-S on our United EFBs/iPads—this should be a goal 
for future projects—and use what is already in the airplane when possible. 


Cite Another option would be to use different, uncertified tablets—again, not 
using class 3 EFBs. 


C12. The trend information provided by the “fast-slow” cue needs to be usable 
at all times to provide information regarding the accuracy of the airplane following 
the assumed deceleration profile. 


How did the FIM-S system work from an operational (pilot/crew) 
perspective? 


C13. The pilots used four different FIM-S software loads during the 19 flying 
days (see Table A-1). 
C14. The first two loads were plagued with instability and required the crews to 


utilize several programing workarounds. The third load, which was used starting 
with the eighth flight, was much more stable. With pilot compensation, the FIM-S 
software was very capable of producing consistent spacing errors of 5 seconds 
or less. The final software load, which was used for the final two flights, optimized 
the actual STAR profiles, which reduced the amount of pilot compensation 
needed. This load provided the best overall results. On the final day of flight 
testing, each of the four runs had a spacing error of 1 second. As a comparison, 
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the average spacing error currently achieved by ATC is approximately 18 
seconds. Improving to 5 seconds or less of error, would result in 11 more landing 
slots per hour to the same runway. 


What improvements need to be made for the next version of FIM/ATD? 


C15. While this phase of testing proved that the FIM-S algorithms do work, 
continued development of the algorithm is needed. An algorithm that maintains 
string stability but more proactively corrects for errors would be an 
improvement. The vertical path and autothrottle performance of different 
airplanes using the system also needs to be incorporated. 


C16. Another round of flight tests, that would demonstrate a more mature FIM- 
S algorithm, along with the ground components of time-based flow management 
that were not demonstrated during NASA ATD-1 (Ground Interval Management - 
Spacing and Traffic Sequencing And Spacing) should be considered. Optimized 
STARs are also needed. 


What is the future of FIM-S from United’s/airline’s perspective? 


C17. The next step for FIM-S is for the industry to advocate for FIM capability 
within the RTCA NextGen Advisory Committee (NAC). FIM could be an important 
component of the northeast airspace initiative, improving operations in the 
northeastern US. There are no other concepts that allow for maintaining VMC 
arrival rates during periods of lower ceilings and visibilities, when visual 
approaches are not possible. To implement FIM-S, either a mandate is needed 
or those who choose to equip should receive preferential treatment. 


4.1.5 Hardware Installation 
United Airlines’ Comments 


C18. The airline/flying partners need to be more involved in the equipment 
selections/specifications during the planning phases of the project. 


C19. For something like FIM-S to be able to be considered for airlines in the 
future, it would need to be able to be run on the airline’s existing EFBs (in 
United’s case it is iPads). United is not going to install a permanent EFB with 
FIM-S if we already have EFBs. This should be considered when developing the 
hardware and software. It would have been much more time and cost effective if 
we could have installed FIM-S on our United EFBs/iPads—this should be a goal 
for future projects—and use what is already in the airplane when possible. 


C20. Another option would be to use different, uncertified tablets—again, not 
using class 3 EFBs (duplicate comment with C11 for added emphasis). 
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4.1.6 Flight Test 
Planning 


Boeing Comments 


C21. The SOW used the term “Flight Test Readiness Review’ to refer to what 
industry would normally call a Test Readiness Review. While the test ultimately 
was a flight test or series of flight tests, there was also bench and ground testing 
required. The term caused a lot of misunderstanding among industry participants. 
Ultimately, the program went with a test readiness review to ensure all the parts 
were ready to start formal on-airplane testing and then conducted flight readiness 
reviews prior to the start of flight test sequences to ensure all the details were 
complete to run the individual flight tests. 


C22. Integrated simulators with Human-in-the-Loop was not done because of 
both cost and schedule constraints. The traveled risk was successfully mitigated 
with expertise and schedule padding but could have gone very wrong. 


C23. A specific example was Falcon pilots having difficulty meeting lead times 
and engaging military SUA along the flight path. Extra coordination with the ATC 
and support from the test directors ultimately mitigated the risks but a lesson was 
learned—include the target pilots in the training simulations even if they only 
observe. 


Execution 


Boeing and Honeywell Comments 


C24. No pre-training of the Falcon pilots was mitigated by having backup flight 
test director ride jump-seat on the Falcon. 


C25. Rotating Falcon pilots required the backup test director to stay on the 
Falcon to help work ATC issues. 


C26. Workload for the Falcon pilots was high between loading the FMC speeds 
for the next approach, maneuvering to adjust the arrival times, and working ATC. 
In this case issue with the Falcon added to that workload as well as poor weather 
early in the flight test. Having the extra pilot on board was used by some crews to 
help reduce that workload. 


C27. The many settings on the Falcon FMS proved problematic in the 
beginning. Examples include the limit on bank angle at altitude, and frequency 
settings. Once these were worked out, the FMS ETAS proved very accurate as 
long as it was set up correctly and the Falcon was inbound on the FMS course. 


C28. Having the Embraer 170 as backup was a very helpful provision that 
Honeywell provided at no additional program cost. 


C29. Situational Awareness is extremely critical for this kind of multi-airplane 
flight test. The ability for the Test Director to see the full big picture proved to be 
the difference between success and failure. When the Planet displays were 
working, the SA was very good and allowed an efficient flight test. 
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C30. Good, effective risk management mitigated the most challenging risks 
and made the program a success. 


C31. Good communication proved essential. 


C32. Organizational communication allowed the many team members to work 
effectively to solve problems as they came up. 


C33. Technical communication, including dissimilar paths was critical; VHF, 
Cell Phone, IM on planet, telephone, and email. 


Professionalism of all the team members, examples include: 


Boeing and Honeywell Comments 


C34. Honeywell pilots figuring out how to get the flight plans filed, including 
United flight plans, even though the national flight plan filing system rejected 
them because of the STARS not being published in the ATC database. 


C35. Pilots collaborated each evening to find workarounds to software issues 
(see Table A-1). 
C36. The airplanes FMS’ ETAs were used to set up the sequences and 


“substitute” for GIM-S tools. This worked with some issues. On the Falcon FMS, 
the ETAs only read out in minutes. The accuracy needed to set up the test 
sequences required seconds resolution. The ETAs, while only reporting in 
minutes, were accurate to within seconds and, after some trial and error, a 
workaround was devised for the Falcon. As the Falcon was coming onto course 
or into the speed range, the ETA change could be tracked and, when it was 
crossing a minute boundary, to point could be noted. This allowed resolving the 
ETA down to 10 seconds and proved quite accurate. As could be expected, 
when maneuvering or off the planned path, including speed, the ETA was not 
accurate. The 737 FMS proved very good at ETAs even when challenged with 
path changes, but that was influenced by pilot technique. 


Program Management 
United Airlines’ Comments 


C37. Develop a draft flight test schedule prior to the beginning of flight test. Any 
known no-fly days should be communicated to everyone prior to flight test 
beginning. For example, NASA knew there would be one Friday or Monday off to 
accommodate their people needing travel back to Virginia per the NASA travel 
policy. This was not made known to the rest of the flight team until the week prior 
to the no-fly day. United (and Honeywell) had people traveling to Seattle, and the 
schedule impacted us a lot more than Boeing or NASA. 


C38. Streamline planning calls; there was a lot of duplication between the flight 
test WG, data collection WG, bi-weekly PM calls, etc. during the planning phases 
of the project. 


United Airlines’ Comments 


C39. All crews should train together, as opposed to training be split into 
multiple groupings. 
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C40. Pilot training should be completed with the FIM-S software that will be 
used during flight test. 


C41. Having both pre- and post-flight briefings after every flight did not seem 
necessary. Especially once we got past the first few flights, it seems like we 
could have had pre-flight briefings on a daily basis and then had post-flight 
briefings on an as-needed basis. 


C42. FIM-S is operationally feasible, but needs to be integrated into the FMC 
and not used on a standalone EFB setup. 
C43. FAA needs to apply FIM-S logic to the design of STARS and transitions to 


approaches, especially to airspeed and altitude windows. 
Boeing Comments 


C44. Coordinating a complex flight test like this one, including 3 vehicles 
interacting, and required a well-informed flight test director. Placing the flight test 
director on the middle airplane, especially the one with good situational 
awareness was critical. Originally the plan was to have the flight test director at 
Boeing field. With the addition of the Planet software for situational awareness, 
moving the flight test director to the 757 proved a very good move. It allowed 
good SA, good communications with the other airplanes, and two paths to 
communicate with the 757 crew, VHF radio for messages that needed to be 
shared with the other flight crews, and intercom for those that did not. 


C45. The simulator training that was done at NASA Langley was very valuable 
for working out operating concepts and coordination techniques. It also allowed 
refining the operating procedures. 


C46. Lead airplane crews understanding the role and criticality of the lead 
airplane in the flight test setup. The simulator facility at Langley did not have a 
Human-in-the-Loop simulator for the Falcon, to the simulations were done using 
a computer surrogate. This was okay but left a large issue both with working out 
procedures for the lead airplane and training the Falcon crews. In hindsight, the 
program should have had the Falcon crews, at least a couple of pilots, train on 
the Langley simulation as Test Directors. This would have allowed them to see 
the “big picture” and better understand the role of the lead airplane. 


C47. Have all the constraints to flight profiles on one diagram rather than 
expecting the crews assimilate data from several sources. The STARS, military 
special use airspace, and civilian ATC sector information were depicted on 
different information sources. While the Falcon pilots had a multidisplay cockpit 
and additional iPads and paper charts, not one of the various tools showed all of 
the constraints. The STARs and Special Use Airspace (SUA) were shown on the 
cockpit displays and the iPads but the Civil ATC sectors and what turned out to 
be a keep-out zone for other civilian flight testing were not. This required the 
pilots to keep track of several different restrictions, which proved very difficult and 
resulted in several frustrations from the ATC controllers. An example was that the 
military SUA was depicted but the controllers wanted a 3 mile buffer from the 
SUA—just keeping out of the SUA was not sufficient. 
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4.2 Conclusions 


The NASA ATD-1 ASTAR algorithm clearly demonstrated the promise of IM operations 
using the Boeing, and Honeywell jointly developed FIM-S avionics in the 19 flying days 
test program. 


During the February 2017 flight testing at Moses Lake, WA, FIM-S avionics on 
Honeywell and United Airlines commercial airplanes flew for 19 flying days to assess a 
FIM-S algorithm based on the NASA ASTAR solution and performance. The flight test 
program has very successfully demonstrated IM operations on 144 merging and in-trail 
spacing runs using a chain of three airplanes. In general, the flight trial clearly 
demonstrated the feasibility of FIM operations as a means to maintain arrival capacity 
during low ceiling and visibilities or high winds by precisely controlling inter-arrival 
spacing. The FIM-S system tested during the ATD-1 flight trial met all but one of the 
MOPS criterion, a remarkable achievement given this was the first prototype FIM-S 
system. 


The FIM-S prototype overall showed good performance through: 1) 19 uniquely different 
flight days (winds, multiple United and Honeywell crews); 2) a variety of realistic initial 
spacing errors (see Table 1); 3) cruise, descent and approach regimes; and 4) several 
off-profile conditions for the lead airplane in the chain (see Table 1). The goal was not to 
confirm if the prototype passes MOPS but to evaluate its performance through flight test. 
The data collection effort confirmed that: 1) delivery performance is close to the MOPS 
at the PTP and ABP throughout; 2) IM speed rate is acceptable although some algorithm 
improvements could make it better, especially for MAINTAIN operations, and 3) the 
capture rate is close to the MOPS criterion, except in extreme conditions. In aggregate, 
time-based operations delivered at the PTP were slightly worse than the MOPS criterion. 
This is mostly driven by CROSS operations. MAINTAIN, SPACE, or CAPTURE 
operations all met the MOPS criteria. 


FIM operations require a smooth nominal speed profile embedded within the procedure 
design as the nominal basis for the control algorithm. Pilot feedback and data analysis 
revealed the impact of route design on FIM-S performance, in particular the altitude and 
speed profile information embedded within the design in the form of altitude and speed 
constraints at waypoints. Given that the route design establishes the baseline profile for 
the FIM-S system, a design that seeks a smoother nominal speed transition along the 
route would lead to less drastic speed changes during IM operations. 


The SE WG made several difficult risk-reduction decisions (and, in hindsight, correct 
decisions) in managing the program to avoid implementation errors and omissions. The 
results produced flight test data for performance and other analysis from well over 80% 
of the recorded data. The accelerated, yet risk- and cost-rational SE steps used 
configuration controlled relational database tools (i.e., DOORS and other tools) 
throughout their SE processes and testing to assess the collected data on 144 Flown 
FIM-S experiments (runs). The team built a successful prototype without following all the 
traditional processes of a fully certified development and test program, yet the team 
maintained traceability of system level design features to the MOPS. MOPS findings and 
flight test data interpretations were documented to be leveraged in future flight test 
planning and/or design activities. This report provides a list of those requirements that 
were not implemented or required additional clarification to support future reviews. The 
software version documentation in Appendix A includes a detailed list of resolved and 
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open test issues. The accelerated SE development processes were successful in that 
they maintained systematic system level requirements traceability throughout the 
documentation hierarchy; this will allow readers to find needed evidence to support 
MOPS standards findings and clarifications. 


Although more development work is necessary for operational implementation, the FIM- 
S system tested during the ATD-1 flight trial met all but one of the MOPS performance 
metrics during flight test. It is remarkable to have the first prototype FIM-S system 
perform as well as it did. The one design goal not met is very close to being achieved, 
and was for one particular geometry and clearance type. There is very high confidence 
that this clearance type and geometry will be corrected prior to any future FIM testing. To 
achieve arrival operations that are integrated with the ATC ground systems end-to-end is 
the ultimate goal and will require solving several issues. Section 4.1 of this report 
describes the lessons learned that illustrate the issues; the next section provides 
recommendations based on the ATD-1 lessons learned to support potential future 
testing. 


4.3 Summary Recommendations 


The 19 flying days testing a FIM-S algorithm based on the NASA ASTAR solution, led to 
productive discussions on the recommendations for future FIM-S testing. The 
recommendations fall into two main categories: (1) expansion of the ATD-1 flight test 
processes and steps to improve and increase the number of successful FIM experiments 
(runs) and (2) future testing to expand the spectrum of realistic IM operations. To further 
decompose the recommendations and improve readability, each of these two areas are 
divided in two subordinate areas: (1a) expand ATD-1 FIM-S flight test planning; (1b) 
enhance ATD-1 FIM-S procedures design and operations; (2a) future prototypes 
development processes (i.e., focused on design cycles); and (2b) accelerated, yet 
affordable, risk planning for future end-to-end flight or other types of testing. 


It should be mentioned that to ensure successful end-to-end flight testing as 
recommended in section 4.3.4, the recommendations in sections 4.3.1 — 4.3.3 should be 
taken into account in the planning of end-to-end testing. 


4.3.1 Expand ATD-1 FIM-S Flight Test Planning 


The report’s lessons learned discussed a number of situations associated with the ATD- 
1 flight test. From these observations, the following recommendations are made: 


e Improved training of flight test personnel (see comments C22-C23): 


" Captain and First Officer: all crews should train together so as to develop 
common/harmonized FIM-S flying techniques. Include training for lead/target 
airplane crew who need to apply the same flying techniques (see comments 
C24—C27, C46). 


= Captain and First Officer: train with the actual software used for flight test (see 
comments C39—C40). 


« Test engineers: harmonize the flying procedures awareness among all support 
personnel such as flight test engineers and others. (see comment C44) 
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« ATC personnel: Multiple ATC coordination briefings were performed for this 
flight test. Simulator training would be critical for future air and ground 
integrated testing of IM operations (see comment C23). 


« Flight test directors: The NASA simulator training was done with the flight test 
directors and this was very beneficial to the execution of the flight test. This 
training should be a model for training other personnel (e.g., ATC, test 
engineers — see comment C45). 


Involve ATC personnel in the experiment design to include criteria for IM 
operations set up (e.g., static and dynamic situations) and real-time spacing 
intervals feasibility checks. (see comment C44) 


Add depictions of the dynamic flight test constraints (e.g., traffic) encountered in 
ATD-1: other traffic performing tests at the airport (i.e., Mitsubishi flight tests), 
extra no-fly margins on the edges of the MOA, crew awareness of their proximity 
to ATC center boundaries, etc. (see comment C47) 


Include a flight testing cycle with actual hardware/software systems (see 
comments C13-C14). 


4.3.2 Enhance ATD-1 FIM-S Procedures Design and Operations 


With ATD-1 flight test complete and many of the MOPS testing criteria reviewed, it is 
necessary to also discuss opportunities to enhance FIM-S procedures design to improve 
IM operations. To this end we recommend the following: 


Apply FIM-S logic (i.e., algorithm speed management criteria, etc.) to design 
STARS and transitions to approaches with optimized IM airspeed and altitude 
windows (see comments C1, C5, C6 and C43). 


Develop and modify existing arrival procedures to allow for additional speed 
authority on the flight deck (see comments C7 — C9, C12) such as using ~2.6 
degrees vertical path descents rather than the 3 degrees of traditional arrivals 
(see comment C1). 


Include ATC in the execution and training of experiments rather than use the 
Test Director’s ‘scripted’ experiment set up information (see comment C1). 


Require baseline FMS performance for RNP AR procedures (see section 2.2). 


4.3.3. Future Prototypes Development Processes 


The report discussed the CPFF nature of the flight test contract, in particular the 
compressed schedule that limited software loads and the number of test cycles to two. 
From the observations discussed throughout the report, the following general 
recommendations for future prototypes development are made: 


Include additional software development test cycles linked to specific test 
objectives (e.g., add one or several flight days for initial software checkout test — 
see sections 2.5, 4.1.1 Display/Human Interface and comment C22). 
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Enhance the FIM-S algorithm (see comments C5 — C9, C15, Table A-5 item 
#273, #274, #276, #278). 


Explore alternative hardware and platform architectures to enhanced PoFV 
displays and augmented data sources integration (see comments C3, C10, C11, 
C18, C19, and C20). 


Include MOPS test vectors for all clearance types in support of hardware-in-the- 
loop system testing. (see sections 2.5 and 4.1.1 Algorithms) 


Include a software usability testing cycle on hardware-in-the-loop test benches to 
enable crew HMI focus group discussions and CDTI layout reviews. (See section 
4.1.1 Display/Human Machine Interface and Table A-5 #275). 


4.3.4 Future End-to-End Flight Test Planning 


The report’s introduction section describes the FAA and NASA efforts at deploying both 
ground automation and airborne capabilities to perform integrated air and ground IM 
operations. The goal is for continued improvement in the level of spacing precision on 
final approach. The full integration with ground ATC systems was not part of this testing 
and should be the primary goal of any follow-on activities. The SE lessons learned 
illustrate important processes to successfully plan a future testing campaign. From the 
programmatic observations discussed throughout the report, the following 
recommendations are made: 


Include integrated ATC (air and ground) technologies including GIM, FIM-S, 
TBFM and RTA (see section 1 and comments C16, C36). 


Test in a mixed datalink and voice environment (see section 1, Table A-5 #277). 


Develop and test a broader set of MOPS test vectors with enhanced procedure 
designs leading to enhanced operations (e.g., see section 2.5 and apply 
recommendation 4.3.3 enhanced with data link test vectors). 


Use accelerated, yet risk and cost rational, processes (i.e., from a funding 
perspective) to integrate air & ground capabilities (e.g., jointly integrate and 
certify air and ground capabilities using ATD-1 accelerated processes — see 
section 1.1 and comment C2). 


It should be mentioned that to ensure successful end-to-end flight testing as 
recommended in section 4.3.4, the recommendations in sections 4.3.1 — 4.3.3 should be 
taken into account in the planning of end-to-end testing. 
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Acronyms 


ABP Achieve-By Point 

ADS-B Automatic Dependent Surveillance — Broadcast 
AID Aircraft Interface Device 

AIRB Airborne Basic Situation Awareness 

ANSP Air Navigation Services Provider 

ARINC Aeronautical Radio, Incorporated 

ASG Assigned Spacing Goal 

ASTAR Airborne Spacing for Terminal Arrivals Routes 
AR Authorization Required 

ARTCC Air Route Traffic Control Center 

ATC Air Traffic Control 

ATD-1 Air Traffic Management Technology Demonstration 1 
ATM Air Traffic Management 

CAS Calibrated Air Speed 

CDR Critical Design Review 

CDRL Contracted Deliverable Requirements List 
CDTI Cockpit Display of Traffic Information 

CGD Configurable Graphic Display 

CMS Controller Managed Spacing 

CONOPS Concept of Operations 

CPFF Cost Plus Fixed Fee 

DO Designation for RTCA DOcument Number 

EFB Electronic Flight Bag 

ETA Estimated Time of Arrival 

FAA Federal Aviation Administration 

NEW D780-10426-1 Page 62 of 74 


FIM Flight Interval Management 


FIM-S Flight Interval Management - Spacing 

FMS Flight Management System 

FRAC Final Review and Comment (RTCA) 

FSI Fast/Slow Indicator 

GFI Government Furnished Information 

GIM Ground-based Interval Management 

GIM-S Ground-based Interval Management - Spacing 
GNSS Global Navigation Satellite System 

HMI Human Machine Interface 

ICD Interface Control Document 

IFPI Intended Flight Path Information 

IFR Instrument Flight Rule 

IM Interval Management 

/O Input Output 

IP Internet Protocol 

ITP In Trail Spacing 

LNAV Lateral Navigation 

MCP Mode Control Panel 

MOA Military Operations Area 

MOPS Minimum Operational Performance Standards 
MSI Measured Spacing Interval 

MWH Moses Lake Airport 

NAS National Airspace System 

NASA National Aeronautics and Space Administration 
NAV DB Navigation Database 
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PDR Preliminary Design Review 


PFoV Primary Field of View 

Pl Progress Indicator 

PSI Predicted Spacing Interval 

PTP Planned Termination Point 

RCAG Remote Communications Air Ground 

RNAV Area Navigation 

RNP Required Navigation Performance 

RTA Required Time of Arrival 

RTCA RTCA Inc., formerly Radio Technical Commission for 
Aeronautics 

SA Situational Awareness 

SAR System Acceptance Review 

SATCOM Satellite Communications 

SDD Software Design Description 

SE System Engineering 

SOW Statement of Work 

SRD System Requirements Document (NASA) 

SRDD System Requirements Definition Document (Boeing) 

SRS Software Requirements Specification 

STAR Standard Terminal Arrival Route 

STP System Test Plan 

SW Software 

TBFM Time-based Flow Management 

TCAS Traffic Alert and Collision Avoidance System 

TG Trajectory Generator 
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T™ Terminal Metering 


TMA Traffic Management Advisor 

TPU Traffic Processor Unit 

TTF Traffic To Follow 

UTC Universal Time Coordinated or UTC Aerospace Inc. 
VHF Very High Frequency 

VNAV Vertical Navigation 

WG Working Group 
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March 2017. (CDRL 4.15) 
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FIM Flight Test Plan (FTP), Deliverable D780-10411-1 Rev B, Dated 8 March 
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Boeing Air Traffic Management Technology Demonstration — 1 (ATD-1) Phase II, 
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(SDD), Deliverable D780-10409-1 Rev A, Dated 6 December 2016. (CDRL 4.4d) 


Honeywell Aerospace — Aerospace — Defense & Space in Support of Boeing Air 
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contract, FIM Avionics Operations Manual (FAOM), Deliverable EG-003690- 
6.16 rev B, Dated 16 January 2017. (CDRL 4.17) 
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Appendix A_ FIM Software Test Issues 


This appendix summarizes the software test issues that were discovered during 
development and testing and that were either deferred before the flight test began or 
were discovered during the flight test itself. Some of these issues were corrected with 
builds released during the flight test program, and some are still open. 


Table A-1 gives a timeline of the flight test and the software build versions that were 
used. For software issues that were corrected, the build number containing the 
correction is listed and can be cross-referenced to this table to determine the impact on 
flight test. 


The remaining tables list items deferred before SAR, issues found during the January 
SAR re-run, issues found in the flight test proper and post-flight test suggestions for 
future work respectively. In these tables, test issues listed in GREEN text are still open. 
Issues listed in BLACK text were corrected in a build sometime before the completion 
of the flight test program. 


A complete listing of all software test issues found during the development phases 
before SAR was delivered as a separate database to NASA in conjunction with the SAR. 
That database included detailed descriptions of the issues found up until that time, 
including the deferred items in Table A-2. An updated summary of test issues was 
included as an attachment to the Software Version Description document [15] 
(deliverable 4.4f) including items found after SAR. 


Table A-1. Flight Test Build Timeline 


Build Usage 
2.0.2 January SAR rerun, 
1/18 Ferry flight/check flight, 
Flight test days 1-3 (1/20 — 1/25) 


2.0.5 Flight test days 4-5 (1/26 — 1/27) 
2.0.8 Flight test days 6-16 (2/1 — 2/16) 
2.1.0 + Flight test days 17-19 (2/20 — 2/22) 


Modified NavDB 


Note: Build are cumulative, i.e. fixes listed for build 2.0.3 and 2.0.4 
were not flown until 2.0.5 installed on 1/26, etc. 


Table A-2. Issues Deferred Before Flight Test 


Issue # Title 
#2 TPU calculated track angle should match heading when velocity is zero 
#43 Non IM Eligible Targets can be manually selected 
#81 Traffic not removed upon TCAS failure 
#89 Naming of PTP ABP before after waypoint not per HMI wireframe 
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Issue # 


Title 


#104 ABP and PTP entry selection shows waypoints that are not common to TGT and 
Ownship routes 

#150 Traffic IM Eligibility - Traffic Velocity Age 

#151 Traffic IM Eligibility - ADS-B Source 

#152 Traffic IM Eligibility - Same Flight Id 

#192 Extrapolation of Target Data 

#203 Incorrect Control Law running when switching clearances 

#209 Default Planned Termination Point insertion 

#219 Speed Commands sometimes shown in non-rounded values 

#232 Procedural Speed Limits not always enforced in the absence of speed change 
commands 

#236 Erratic display of Target Absolute Altitude 

#237 IM DB NOT CURRENT does not force UNABLE 

#244 FAST/SLOW Indicator changes are required 

#246 When selected PTP does not have a speed constraint, the wrong default is 
sometime applied 

#249 Sudden Change in Nominal profile limit during Transition to After PTP (probably 
caused by ground speed matching) 

#250 PTP ABP selection At/Before/After Runway not working correctly (closed - not 
reproducible in current build) 

#252 Default PTP selection when no runway is entered in IFPI 

Table A-3. Issues found during SAR rerun 
Issue # Title/Status 

#253 Changing the Waypoint from Slave corrupted Waypoint Entry list 
Fixed in build 2.0.3 

#254 HMI can show inconsistent Runway and Flight Path elements 
Fixed in build 2.0.3 

#255 Navigation database cycle dates annunciation 
Found after SAR (with new Nav DB) 
Fixed in build 2.1.0 

#256 Not able to see all STARs associated with an Airport once a runway has been 
selected 
Fixed in build 2.0.4 
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Table A-4. Issues Found During Flight Test 


Issue # Title/Status 
#257 Waypoints not shown in ABP and PTP menus 
e Found on ferry flight/check flight 
e Work-around used during flight test 


e Problem may have been fixed by subsequent builds, but is still listed as 
Active 


#258 Descent winds lost when clearance information is re-entered (or even just looked 
at?) 

Work-around used for some flights 

Fixed in build 2.0.6 

#259 OWNSHIP ENTRY page sometimes shows TARGET ENTRY as title 
No work-around (never reported as a problem by the flight crew) 
Fixed in build 2.0.6 

#260 CTD Algorithm Maintain Time-History (THDB lookup problem) 
Partial work-around was to fly the Falcon like an air transport jet 
Several fixes tried, final fix in build 2.0.9 

#261 BAD ROUTE — Upstream Speed Constraint 


Ultimately caused by a complicated interaction between low altitude “cruise” 
segments and inappropriate deceleration parameters 


Fixed in build 2.0.5 
#262 Target Bearing and Range missing from CTDI 


e Work around was to use RTA, Planet and other ADS-B data for test 
director situational awareness 


e Root cause found, but not fixed yet, listed as Active 


#263 Re-entering runway clears all data except Destination airport 


e Actual problem is slightly more complicated than title implies — the data is 
cleared but the new data isn’t used if a previous clearance was active at 
the time of the change 


e = Fixed in build 2.0.3 

#264 SUSPENDED or UNABLE with no fault message & system must be reset to 
recover 

Traced to buffer overrun in Trajectory Generator 

Fixed in build 2.0.8 


#265 Trajectory "loops" back to start of IFPI 
Work around was to wait after arming until route stabilized before executing 


Software fix was to add comparison of distance to destination for candidate 
active legs as well as cross track error and heading 


Fixed in build 2.0.8 
#266 (duplicate of #258) 


#267 Dropped upstream speed constraints cause incorrect speed profile 


Problem affected Target TG regens. Previously sequenced speed constraints 
wouldn’t be applied and the calculated speed profile would be incorrect 


Fixed in build 2.0.7_ Interim 
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#268 Cruise/Descent Profile entry page CLEAR button sets bad default cruise altitude 
Work around was to avoid using the clear function when updating the profile 
Fixed in build 2.0.8 


#269 TG Regen reason appears to be incorrect in the logs 


e Did not affect flight testing but may affect data analysis — needs to be 
kept in mind when interpreting log data 


e = Still listed as Active 


#270 (deleted) 
#271 TG regens when target is past PTP cause bad route and IM UNABLE 
e Can also occur when target passes ABP but before CTD algorithm 
applies 


e Would require requirements analysis to determine best solution 
e = Still listed as Active 


#272 Transient faults causing IM AVAILABILITY fail not handled properly 

e Temporary drop in GPS integrity caused system to not be eligible for IM 
e Fault was not logged correctly or cleared properly when GPS returned 
e = Still listed as Active 


Table A-5. Post Flight Test Issues/Suggestions for Future Work 


Issue # Title/Status 
#273 Add hysteresis to CTD gain schedule 


e Small variations in spacing error could cause different gain values to be 
used and could cause extra speed commands to be issued 


e Listed as Deferred 
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#274 


Develop complete Mach Control Law 


e Current speed control implementation uses ad hoc methods to control 
the speed in the Mach regime 


e Worst case behavior could theoretically cause soeed commands in the 
wrong direction 


e Listed as Deferred with detailed description provided here: 


The Mach handling existing in the current baseline was developed to satisfy the 
need to quickly define a basic set of rules designed to provide acceptable 
performance under common conditions. It should be evaluated whether 
development of a more complete Mach Control Law is warranted. Topics to be 
considered would include: 
(1) performance when selector is not left at its 'default’ setting (ex. outputting 
Mach commands below the Crossover Altitude), 
(2) limiting (including nominal profile limiting as well as IM Speed Upper Limit 
and Mmo - conversion of Mach limit values to CAS can result in "rounding" 
which further restricts the limits), 
(3) CAS/Mach conversions when ownship is not flying its nominal altitude 
profile (ex. ownship begins to descend early relative to the nominal TOD. For 
TBO, in the case of needing to incorporate a speed correction, the sum of the 
nominal profile CAS and the speed correction are converted to Mach based 
on the reported altitude, not the nominal altitude at which the nominal CAS 
was derived. If the altitude differences between reported and nominal are 
very large (very close to the TG re-generation limit), this could possibly lead 
to Commanded IM Speed values in the opposite trend of the correction. 


#275 


Proposed enhancements from HMI dev team 


e Improvements to dialogs, text boxes, symbology and HMI controls are 
suggested 


e (Details listed in Test Issue DB) 
e Listed as Deferred 


#276 


MACH/CAS speed limits should be separate and independent 
e NASA suggested improvement 


e The Mach/CAS page should have a separate minimum and maximum 
limits entered, and the software should apply those limits only when the 
airplane is within that regime 


e Listed as Feature Request 


#277 


Wind data entry should come from datalink 
e NASA suggested improvement 


e The data entry of wind data was time consuming and prone to error. 
Hopefully some form of datacomm or ACARS will be available in the 
future 


e Listed as Feature Request 


#278 


Speed Control enhancements suggested by NASA 


e Recommendations are provided to improve pilot acceptability of the 
speed commands 


e (Complete details listed in Test Issue Database, partial list under #274) 
e Listed as Feature Request 
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#279 "Shadows" in reported spacing interval 


e When TTF passes the ABP, the reported spacing interval often shows a 
distinct noise pattern that looks like a second, shadowing, curve offset 
slightly from the primary curve. 


e = Listed as Active 


#280 For distance-based clearances, the gain schedule in the requirements does not 
reflect the gain schedule implemented in the software 
e Based on observed speed control performance at SAR, NASA requested 
changes to the distance-based gain schedule. These changes were 
incorporated into the flight software, but the software requirements and 
code tags have not been updated with the new values yet. 


e Listed as Deferred 


NEW D780-10426-1 Page 73 of 74 


Revision Record 


Release/Revision NEW 


Limitations 

Description of New document. 

Change 

Authorization for 

Release 

AUTHOR: Signature on file 156035 
Paul A. van Tulder BEMSID 
9M-PW-ERCS 06/01/2017 
Organization Number Date 

APPROVER: Signature on file 83438 
Karl Rein-Weston BEMSID 
9M-PW-ERCS 06/01/2017 
Organization Number Date 

DOCUMENT RELEASE: Signature on file 115298 
Barbara L. Withers BEMSID 
9M-PW-ERCS 6/1/2017 
Organization Number Date 


NEW D780-10426-1 Page 74 of 74 


REPORT DOCUMENTATION PAGE PRE 


The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data 
sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other 
aspect of this collection of information, including suggestions for reducing the burden, to Department of Defense, Washington Headquarters Services, Directorate for Information 
Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. Respondents should be aware that notwithstanding any other 
provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. 
PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 


1. REPORT DATE (DD-MM-YYYY) | 2. REPORT TYPE 3. DATES COVERED (From - To) 
01- 06- 2017 Contractor Report 


4. TITLE AND SUBTITLE . CONTRACT NUMBER 
NNL13AA03B 
Flight Deck Interval Management Flight Test Final Report - GRANT NUMBER 


. PROGRAM ELEMENT NUMBER 


6. AUTHOR(S) . PROJECT NUMBER 


Tulder, Paul V. . TASK NUMBER 


NNLI5AB46T 
.» WORK UNIT NUMBER 
330693.04.10.07.09 


7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION 
REPORT NUMBER 


NASA Langley Research Center 
Hampton, VA 23681-2199 


9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR'S ACRONYM(S) 


National Aeronautics and Space Administration NASA 
Washington, DC 20546-0001 


11. SPONSORIMONITOR'S REPORT 
NUMBER(S) 


NASA-CR-2017-219626 


12. DISTRIBUTION/AVAILABILITY STATEMENT 


Unclassified - Unlimited 
Subject Category 03 
Availability: NASA STI Program (757) 864-9658 


13; SUPPLEMENTARY NOTES Langley Technical Monitor: Denise K. Scearce 


14. ABSTRACT 


This document provides a summary of the avionics design, implementation, and evaluation activities conducted for the ATD-1 Avionics 
Phase 2. The flight test data collection and a subset of the analysis results are described. This report also documents lessons learned, 
conclusions, and recommendations to guide further development efforts. 


15. SUBJECT TERMS 


ATD-1; Airspace management; Aviation; FIM 


16. SECURITY CLASSIFICATION OF: . LIMITATION OF | 18. NUMBER/ 19a. NAME OF RESPONSIBLE PERSON 


ABSTRACT OF 
PAGES STI Help Desk (email: help@sti.nasa.gov) 


79 19b. TELEPHONE NUMBER (Include area code) 
U U U UU (757) 864-9658 


Standard Form 298 (Rev. 8/98) 
Prescribed by ANSI Std. Z39.18 


a. REPORT b. ABSTRACT | c. THIS PAGE 


